Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^15: ref to read-only alias ... why? (notabug)

by ikegami (Patriarch)
on Jan 07, 2012 at 01:09 UTC ( [id://946693]=note: print w/replies, xml ) Need Help??


in reply to Re^14: ref to read-only alias ... why? (notabug)
in thread ref to read-only alias ... why?

But my objection is that for(1..3) construct doesn't do aliasing

That's not true. Exactly the same aliasing occurs for both for(1..3) and for(1).

"intentionally returns a modifiable value (in a sense) some of the times" mean

Intentionally coded to return a value that can be changed without causing a read-only error.

Replies are listed 'Best First'.
Re^16: ref to read-only alias ... why? (notabug)
by dk (Chaplain) on Jan 08, 2012 at 19:46 UTC
    Exactly the same aliasing occurs for both for(1..3) and for(1).

    I'm sorry, but you're dead wrong here:

    my $a = 2; $_++ for 1..$a; print "$a\n"; # 2 my $a = 2; $_++ for $a; print "$a\n"; # 3
    clearly, there are two different mechanisms: the first does not do aliasing, whereas the second does.

    But anyway, I still don't understand the "working case" you referred to that my patch will break. Could you please produce that?

    Intentionally coded to return a value that can be changed without causing a read-only error.

    Is there any proof of that intention? Best in perldoc?

      clearly, there are two different mechanisms: the first does not do aliasing, whereas the second does.

      How can you claim that for(1..3) doesn't alias when you can clearly see ++$_; having an effect on what it returns?

      In both for(1..3) and for(1), $_ is aliased to each value returned by the expression in the parens.

      I'm sorry, but you're dead wrong here:

      First, your example does not demonstrate a lack of aliasing. It just shows that $_ isn't aliased to $a. That's to be expected, because 1..$a doesn't return $a anymore than 0+$a does.

      Second, you pulled a switcheroo. I said for(1..3) aliases (and proved that it does), but your code uses for(1..$a). for(1..$a) is implemented differently; it's a counting loop and not a foreach loop. It still aliases, though.

      Is there any proof of that intention? Best in perldoc?

      There was code written to specifically perform this effect. By definition, the effect must be intentional.

        Ok, I agree about for (1..3), that's reasonable. But I don't agree on this:

        There was code written to specifically perform this effect. By definition, the effect must be intentional.

        If it were true, why then threaded and non-threaded perl give different results in \ $_[0] ? Was that also intentional? Even if it was, that's bad intention to me, and bad design. A bug, basically.

      my $a = 2; $_++ for 1..$a; print "$a\n"; # 2

      thats a confusing example, nothing else than

      my $a = 2; $_++ for 1..2; print "$a\n";

      I don't understand what it's supposed to prove.

      Cheers Rolf

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://946693]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2024-03-19 10:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found