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
magic autogeneration does not work as expected for ++ and -- #8945
Comments
From perl@plan9.deCreated by perl@plan9.deThe MAGIC AUTGEBNERATINO section in perldoc overload says: Increment and decrement The "++$a" operation can be expressed in a+=1" or "$a+1", and "$a--" in This leads me (I might be wrong) to believe that if an overlaoded value $value = $value + 1 But this is not the case: use overload my $value = bless \(my $dummy = 1), __PACKAGE__; warn ++$value; This outputs, on my system, the number 6886977 instead of the expected 2. Using $value = $value + 1 gives me the expected result of "2". One could argue that $value++ falls back to the non-overloaded way of (Or otherwise some hint in the documentation that you have to overload ++ Perl Info
|
From @HugmeirOn Sat Jun 23 16:32:43 2007, perl@plan9.de wrote:
PATH=/root/s2:/root/s:/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/root/src/uunet:.
While the code's behavior hasn't changed, overload.pm has a "Minimal Set |
The RT System itself - Status changed from 'new' to 'open' |
From schmorp@schmorp.de
Hmm, the section doesn't seem to be related to the problem at hand, as it is Maybe you mean this section: Of the conversions, only one of string, boolean or numeric is needed But I don't see how that would mean that "0+" is not used when the value -- |
From @HugmeirOn 5/25/12, Marc Lehmann <schmorp@schmorp.de> wrote:
Nah, that wasn't that I meant. The Magical Autogeneration section has |
From schmorp@schmorp.deOn Fri, May 25, 2012 at 12:30:16PM -0300, Brian Fraser <fraserbn@gmail.com> wrote:
That's what you claim, but nothing in the documentation supports that, As I wrote before (did you read my mail?) the goal is not to have a full And for that, the documentation section you mentioned clearly says that it Of the conversions, only one of string, boolean or numeric is So where in the documentation does it say that ++ ignores overloaded -- |
From @HugmeirOn Sat, May 26, 2012 at 1:15 AM, Marc Lehmann <schmorp@schmorp.de> wrote:
Aren't you misreading that? To phrase it differently, it says "Of the three |
From schmorp@schmorp.deOn Sat, May 26, 2012 at 01:37:36AM -0300, Brian Fraser <fraserbn@gmail.com> wrote:
No.
Both readings indicate a bug, because in the example, perl doesn't do any So if the set of operations is "all conversions" or "everything" doesn't I think the problem is that, despite me telling you otherwise multiple The fact that it works with + should be a dead giveaway that something is If the goal were to have an overloaded + or ++, it obviously would have to -- |
From @rjbsAfter reading this documentation over and over, I believe that the Further, I think it's pretty surprising. My gut feeling (and I have not given it a lot of careful thought yet) is On the other hand, improving the documentation should be quite possible, |
From schmorp@schmorp.deOn Sat, May 26, 2012 at 05:38:04AM -0700, Ricardo SIGNES via RT <perlbug-followup@perl.org> wrote:
Could you explain your reasoning on why overload does not support partial As such, improving the documentation to enforce a state that isn't reality is All I get from you guys is "it's correct as documented", ignoring the I think if you really think the documentation says what it doesn'T say One could probably document that ++ (because it is both a string and
Right, it's especially surrpising because it isn't true - all built-in Furthermore, if all operators would have to be overloaded, then the The documentation is pretty clear that partial overloads are o.k., because And since it's clearly not true, even *if* it woudls ay so, it would
The real question is whether the ++ and -- behaviour could be synthesized I also don't think that some code relies on the fact that ++ and -- -- |
From @cpansproutOn Sat May 26 05:38:03 2012, rjbs wrote:
I think the subject of this ticket is misleading. It’s not Let’s take eq as an example. If I have fallback set to undef, then If I set fallback to 1, then eq won’t be directly autogenerated from ""; It seems that ++ has a bug in it that is stopping it from nummifying
And I hope I have convinced you it is a bug. What I wrote above is an armchair response, so it may be off. I haven’t
I hope not. :-) -- Father Chrysostomos |
Migrated from rt.perl.org#43356 (status was 'open')
Searchable as RT43356$
The text was updated successfully, but these errors were encountered: