Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error message for Buf and eq or ~ operator: Cannot use a Buf as a string, but you called the Str method on it #2872

Open
p6rt opened this issue Aug 27, 2012 · 3 comments
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Aug 27, 2012

Migrated from rt.perl.org#114614 (status was 'open')

Searchable as RT114614$

@p6rt
Copy link
Author

p6rt commented Aug 27, 2012

From @ronaldxs

The eq and similar string operators are allowed for comparing (same bit
size?) buffers as documented in S32 -
http://perlcabal.org/syn/S32/Containers.html#Buf_Operators. This is
useful for finding things in Bufs like CRLF sequences in http headers.
I tried comparing something like Buf.new(13, 10) eq $tcp_recv_buff[ $i,
$i +1] and it failed with the above error message because I am trying to
compare a buf to parcel. It was later shown by TimToady++ that for the
$tcp_recv_buff I should have been using the subbuf method.

The error message "Cannot use a Buf as a string, but you called the Str
method on it" seems to confusingly imply that Buf does not use the eq
operator when in the right context it does. Even if one compared
Buf.new(65, 66) eq 'AB' a better error message might tell the user
something like "Can only do string equality between Bufs or Str
converted/decoded Buf and Str". Buf.new(65, 66).decode('utf-8') eq 'AB'
works but Buf.new(65,66) eq 'AB'.encode('utf-8') works too and might be
the needed answer if, for example, you are not sure whether the Buf
properly decodes to 'utf-8' or not.

There is a similar issue with the ~ operator. For example​:

perl6 -e 'my $x = Buf.new(65); $x ~= Buf.new(66); say
$x.decode("ascii")'
AB
perl6 -e 'my $x = Buf.new(65); $x ~= "B"; say $x.decode("ascii")'
Cannot use a Buf as a string, but you called the Str method on it

There is no problem with Rakudo not appending a string to Buf but again
the error message could be more informative and explain that ~ works on
Bufs just not Bufs combineed with Strings.

Ron

@p6rt
Copy link
Author

p6rt commented Aug 28, 2012

From @moritz

On Mon Aug 27 10​:23​:45 2012, ronaldxs wrote​:

The eq and similar string operators are allowed for comparing (same bit
size?) buffers as documented in S32 -
http://perlcabal.org/syn/S32/Containers.html#Buf_Operators. This is
useful for finding things in Bufs like CRLF sequences in http headers.
I tried comparing something like Buf.new(13, 10) eq $tcp_recv_buff[ $i,
$i +1] and it failed with the above error message because I am trying to
compare a buf to parcel. It was later shown by TimToady++ that for the
$tcp_recv_buff I should have been using the subbuf method.

The error message "Cannot use a Buf as a string, but you called the Str
method on it" seems to confusingly imply that Buf does not use the eq
operator when in the right context it does.

More to the point, the multi variant you called, infix​:<~>(Cool, Cool),
does indeed not deal with Buf objects. Giving a better error message
would require the addition of two multi candidates per infix operator
that Buf deals with, a total of 24 more candidates, and I'm not sure
it's worth it. Any opinions from others on that topic?

(And perhaps it would be less confusing to have the error message says
"but you used it in string context", because it's not the user who
called the .Str method).

@p6rt
Copy link
Author

p6rt commented Aug 28, 2012

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

1 participant