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
> DC> * Label an argument such that there is no corresponding named
> DC> parameter.
>
> Could this be eased slightly? How about a %rest hash, if supplied
> in the prototype would absorb the unused named parameters?
Yes, I've been rethinking that in light of my i
> "DC" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
DC> * Label an argument such that there is no corresponding named
DC> parameter.
Could this be eased slightly? How about a %rest hash, if supplied
in the prototype would absorb the unused named parameters?
DC> =hea
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.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 18 August 2000
Last Modified: 18 August 2000
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 17 August 2000
Version: 1
Mailing List: [EMAI
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
Peter Buckingham <[EMAIL PROTECTED]> writes:
>
>There are a couple of reasons for overloading. simple arithmetic operations, you
>can use plus(int, int), plus(float, float). another approach is to use
>genericity like in eiffel, and the templates in C++, which is probably better in
>the sense that
David L . Nicol <[EMAIL PROTECTED]> writes:
>It will run faster, because it doesn't have to evaluate
>the want(). (97,98) doesn't invalidate the current way of doing
>things, it just gives a new way. And in syntax that is currently
>erroneous.
Consider :
sub outer
{
$object->aSub;
}
The
> 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
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 behavio
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
22 matches
Mail list logo
