Re^5: Why doesn't SUPER cause dead loop here?

Did you read what you linked to?

And despite this, you understand the left hand side has to be evaluated before the right

Quite the opposite, I understand the this isn't true at all. Perl is free to place the contents of @_ on the stack before evaluating the shift(@_).

There's nothing in the linked post to support your statement. It states what Perl *does*, not what Perl *must do*. In fact, it contradicts your statement because it specifically points out that other behaviours are possible.

and in perltoot since about perl-5.004, 14 years ago

uh, nowhere in perltoot or in the other document you linked is @_ both used and modified in the same statement, much less the more specific shift->foo(@_).

In case there's any confusion, shift->foo() and $class->foo(@_) are perfectly safe, it's shift->foo(@_) that's not.

Comment on Re^5: Why doesn't SUPER cause dead loop here? Select or Download Code

Replies are listed 'Best First'.
Re^6: Why doesn't SUPER cause dead loop here? by Anonymous Monk on Sep 02, 2011 at 09:07 UTC
Did you read what you linked to? Yes , did you? In case there's any confusion, shift->foo() and $class->foo(@_) are perfectly safe, it's shift->foo(@_) that's not. And still, its used all over CORE	[reply]
Re^7: Why doesn't SUPER cause dead loop here? by ikegami (Patriarch) on Sep 02, 2011 at 09:37 UTC
Yes , did you? Yes. There's nothing in the linked post to support your false that Perl must execute the `shift(@_)` before the `@_` on the right. Nowhere in perltoot or in the other document you linked is `@_` both used and modified in the same statement. None of the three links show what you claimed they do. And still, its used all over CORE Thank you. This is all I asked for. So much code using that undocumented behaviour means it's not likely to change, at least not without a good long deprecation cycle.	[reply] [d/l] [select]