Buddha Buck wrote:
> 
> At 09:21 AM 8/17/00 -0700, Nathan Wiger wrote:
> 
> >    $cgi->param($var, @val);      # traditional
> >    $cgi->param($var) = @val;     # lvalue, but same thing
> >
> >The second one, then, just makes it more obvious what's going on. But it
> >shouldn't change the behavior of the sub. In fact, these two should
> >*both* be valid options for setting $var. Then the programmer can choose
> >their preferred style.
> 
> OK, this is where we differ.  I see no reason why those two should
> necessarily be the same.  Why couldn't the first be a normal function
> (returning an rvalue) rather than an assignment?

I don't think your and my approaches are necessarily incompatible. But
both of us would have to compromise a little. In the above examples, I
don't see why it couldn't return a value *and* do an assignment. This is
why I think Andy's simple proposal is so robust:

1)  $date->format('HH:MM');     # set format, discard results
2)  $oldformat = $date->format('HH:MM');  # same, save results

3)  $date->format = 'HH:MM';    # set format, discard results
4)  $oldformat = $date->format = 'HH:MM'; # same, save results

Making the subs work differently would necessitate something like having
to use form (2) if you wanted the value back, but use form (3) if you
want to set the value. This part strikes me as silly.

> To me, it's "clear" that the first version is properly written as:
> 
> $tree->path('L','R','R');
> 
> and the second as:
> 
> $tree->path('L','R')='R';

What if you wanted to do something like this:

   $oldpath = $tree->path('L','R') = 'R';

Now, here's a compromise that I think could meld the two RFC's together:

   1. Make the lvalue subs be able to take different
      args and do stuff slightly differently (Nat's)

   2. But overall, make them work exactly the same as
      rvalue subs if you want them to (Andy's)

So, per Andy's proposal, put everything in @_. However, take Nat's idea
and allow for special slots in an lvalue context. That way, I as the
author can either make the lvalue sub work like a normal sub (so I can
cascade them), or as a very specialized sub (so I can get the benefits
of the = operator like your example). TMTOWTDI.

Thoughts? Everyone's acting like the two are incompatible but I don't
think they are at all. If Nat's RFC makes the :lvalue arglist optional I
think the two can be merged as-is (assuming everyone compromises just a
little).

-Nate

Reply via email to