Nathan Torkington wrote:
>
> I think I failed to explain Damian's use of the word 'dangerous'.
>
> my $var;
> sub routine {
> $var;
> }
>
> This, by virtue of rvalue subs being default, keeps the lexical $var
> private. Damian's big on privacy.
> (2) Changing variables in the subroutine's scope is a BIG THING, and
> ought to be explicitly enabled, rather than explicitly disabled.
Ok, this a good issue. And I wasn't trying to be rhetorical. :-) The RFC
states that "lvalue subs will be directly equivalent to rvalue subs".
That's what I was basing my statements off.
If that's not true, and stuff like variable scoping is still going to be
a tricky concern, then the RFC should mention this. In that case, I'll
certainly put up with Andy's "use lvalue" pragma idea.
Nonetheless, I think a better thing would be to figure out if it's
possible to "fix" this issue. I would *really* like lvalue subs ==
rvalue subs.
> (3) :lvalue is hardly rocket science. You drastically overstate its
> complexity.
I strongly disagree with this. You know how many people have problems
with my? Lots.
The concept isn't that hard ":lvalue makes it so you can assign to
subs". But the hard part is deciding *where* it should be used. I think
it puts an unfair burden on a CPAN author to try and forsee all the
possible uses of a sub.
A later example I sent out shows, I think, how someone could miss a
really great use of a sub that seems like it should only be rvalue-able:
@result = ($first, $second, $r->fix_chars) = split /:/, <PASSWD>;
If the author doesn't forsee this, then I have to ask them to patch it.
What if they're busy? Or aren't interested? Do I have to hack the module
to make something that works just fine actually work?
If lvalue subs are *exactly* like rvalue subs (as the RFC says
currently) then keeping the :lvalue makes no sense. I think this should
be the goal: to truly make them "directly equivalent" as the RFC states.
If we can't do this, then we can fall back to a "use lvalue" pragma at
the last minute.
-Nate
