Nathan Wiger <[EMAIL PROTECTED]> writes:
> Nathan Torkington wrote:
> > Not every subroutine corresponds to a method call exposing
> > object-internal data. Most of my subroutines *do* something and make
> > no sense to be called lvaluably. Explicit marking the compiler pick
> > up assignments to non-lvaluable subroutines. It makes sense to
> > explicitly mark the rare cases (:lvalue), rather than the common
> > (:no_assignment).
>
> Well, this argument makes more sense. However, I still have to disagree.
> In fact, I think the opposite: ALL subs *should* be lvaluable by
> default. Here's why.
>
> One word: CPAN (ok, an acronym :). Let's take CGI.pm as an example.
> Currently, you can do this:
>
> $val = $cgi->param($name); # get the param
> $cgi->param($name, $val); # assign a val
>
> So, it seems the next logical extension would be this:
>
> $cgi->param($name) = $val; # assign a val
>
> No problem. In fact, this fits under your rules. HOWEVER, it also
> assumes that Lincoln thought that param() was :lvalue-worthy. What if he
> forgot? Or didn't think of this case?
Hmm... on a cursory glance at CGI.pm it would appear that just doing
sub param : lvalue {
At the beginning of the param definition will make it Just Work(tm).
And if lvalue access were made the only way of doing assignment of
params in this context then a whole bunch of the code in param could
be removed.
--
Piers
