> I think we agree.
>
> $foo is a tied variable
> $bar is a normal variable
>
>sub zap : lvalue { return $_[0] ? $foo : $bar }
>
>zap(1) = 5; # Goes to tied variable
>zap(0) = 5; # Normal store
And it would also be good to be able to overload oper
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Fri, Aug 18, 2000 at 12:25:42AM -0400, Chaim Frenkel wrote:
>> As Graham pointed out, is an lvalue sub supposed to act like a tie or
>> like a variable.
GB> Both.
GB> As Damian points out the lvalue sub must return something that can
On Thu, Aug 17, 2000 at 05:10:40PM -0400, Buddha Buck wrote:
> SO what you are saying is that the proper execution of "$p->foo(@args) +=
> $val;" should be (equivalent to):
>
> 1. Evaluate $val and get an rvalue $rval.
> 2. Evaluate $p->foo(@args) and get an lvalue $lfoo.
The order of those tw
On Fri, Aug 18, 2000 at 12:25:42AM -0400, Chaim Frenkel wrote:
> As Graham pointed out, is an lvalue sub supposed to act like a tie or
> like a variable.
Both.
As Damian points out the lvalue sub must return something that can
be used as an lvalue. Normal assignment hen happens.
So the result w
Then assignment is the gatekeeper?
But what information will the lvalue sub have for deciding what to
make lvaluable?
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> And I keep pointing out that this is only one aspect of lvalue subroutines.
DC> The point of an lvalue subroutine i
As Graham pointed out, is an lvalue sub supposed to act like a tie or
like a variable.
If it acts like a variable it can't be a gatekeeper.
Hmm, what if the sub gets a chance to look at the value before acting.
Checks the value. If good returns a reference to the correct variable
to save it in.
At 05:49 AM 8/18/00 +1000, Damian Conway wrote:
>And I keep pointing out that this is only one aspect of lvalue subroutines.
>The point of an lvalue subroutine is not to make assignment to the return
>value
>work, it is to make the return value an *lvalue*. That's a much more general
>thing, bec
Buddha Buck <[EMAIL PROTECTED]> writes:
> > $cgi->param($var) += ...
>
> This is not a pure lvalue, but rather both an lvalue and an rvalue,
> equivalent to:
>
> $cgi->param($var) = $cgi->param($var) + ...
>
> It should evaluate $cgi->param($var) twice, once as an rvalue, and
> once
Damian Conway <[EMAIL PROTECTED]> writes:
> The point of an lvalue subroutine is not to make assignment to the
> return value work, it is to make the return value an *lvalue*.
> That's a much more general thing, because it allows every other type
> of modification to work too.
Exactly!
-- Johan
[Quoting Graham Barr, on August 17 2000, 18:32, in "Re: RFC 118 (v1) lva"]
> if $b happens to be tied and FETCH returns a different value to what
Yes, tie is along the same lines.
-- Johan
> I hate to add a "me too" but I think this is right on. I also think that
> Nat's proposal and several other discussions overlook some stuff about
> lvalue subs. Most of the places I've seen them used really well is if
> they walk and talk like other forms:
>
>$cgi->param($
At 07:04 PM 8/17/00 +0200, Johan Vromans wrote:
>Nathan Wiger <[EMAIL PROTECTED]> writes:
>
> > Most of the places I've seen them used really well is if
> > they walk and talk like other forms:
> >
> >$cgi->param($var, @val); # traditional
> >$cgi->param($var) = @val; # lvalue, bu
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 sh
On Thu, Aug 17, 2000 at 07:04:40PM +0200, Johan Vromans wrote:
> And, what would the lvalue routine return? Currently, $a = $b = $c
> implies that both $b and $a get the value $c. But with lvalue subs I
> can write something like
>
> yech($foo) = $bar
>
> that assigns $bar to $foo, and retu
Nathan Wiger <[EMAIL PROTECTED]> writes:
> Most of the places I've seen them used really well is if
> they walk and talk like other forms:
>
>$cgi->param($var, @val); # traditional
>$cgi->param($var) = @val; # lvalue, but same thing
I do not think this is critical. When lvalue
Andy Wardley wrote:
>
> I'm inclined to say that assignments of the form:
>
> $foo->bar(@baz) = @boz;
>
> Are allowed, but just plain stupid. It's the same as:
>
> $foo->bar(@baz, @boz)
>
> and you're right, Perl can't tell the lvalues and rvalues apart. So
> don't do that.
I hate t
On Aug 16, 8:21pm, Perl6 RFC Librarian wrote:
> # this is perl6
> sub foo :lvalue ($new) {
> $variable = $new;
> }
A nice idea, but one of the reasons for the original proposal was
to make
$foo->bar = $x;
behave the same as:
$foo->bar($x);
Your proposal provides a neat solution
During -internals discussions, we seem to have come up with, that the
flattenting will not be required by the implementation. (It might actually
be a win.)
All arrays/lists would be actually have a single reference on the data
stack. For backwards compatiblity, @_ would iterate of all arguments.
> This would change the perl5 meaning of lvalue subroutines. Currently
> you must have the lvalue as the last value before the return, and the
> assignment is implicitly done by Perl. I advocate making it explicit:
>
> # this is perl5
> sub foo :lvalue {
> $variable
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
lvalue subs: parameters, explicit assignment, and wantarray() changes
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Aug 16, 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
20 matches
Mail list logo
