in reply to Re: Experimenting with Lvalue Subs
in thread Experimenting with Lvalue Subs

I thought about that too but one problem is order of evaluation. In order to provide the rvalue to the sub, you would have to evaluate the right hand side before the left hand side and that's odd or possibly even bad (I'm not exactly sure yet).

I've also seen Larry Wall say somewhere that tieing is the way you will have to do this in Perl 6 (although it will be considerably more straight forward that in Perl 5)

Replies are listed 'Best First'.
Re^3: Experimenting with Lvalue Subs
by BrowserUk (Patriarch) on Jan 24, 2005 at 22:24 UTC
    ...you would have to evaluate the right hand side before the left hand side...

    I'm not sure that I understand you. The right-hand side of an assignment is always evaluated before the assignment can occur? Except maybe in the case of assigning a constant, but even then the value of that constant is fetched from wherever before it can be assigned to the lvalue.

    It's quite possible that I do not fully grasp the purpose or magic that lies behind the implementation of lvalue subs, but any code in an lvalue sub is invoked as a sideeffect of the assignment to an lvalue sub: 

    { my $x; sub x: lvalue { print 'fred'; $x } };
x = 123;
fred

    [download]

    The problem is that you can't do anything useful with that code as you cannot affect the outcome of the assignment relative to the value being assigned.

    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
[reply]
[d/l]
      Yes, that part was nonsense, sorry about that. However Larry has officially declared tie as the way to do it for other reasons (see my reply to LR above).
[reply]

        I just saw that and read the pertaining bits of apo6. In particular

        RFC 107: lvalue subs should receive the rvalue as an argument

        This would make it hard to dynamically scope an attribute. You'd have to call the method twice--once to get the old value, and once to set the new value.

        The essence of the lvalue problem is that you'd like to separate the identification of the object from its manipulation. Forcing the new value into the same argument list as arguments meant to identify the object is going to mess up all sorts of things like assignment operators and temporization.

        Which, without some form of explaination of how it "is going to mess up all sorts of things" and why those things are considered more important than the ability to validate the assigned value, sounds an aweful lot like "because I said so" :(

        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
[reply]

In Section Meditations