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

...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.

Replies are listed 'Best First'.
Re^4: Experimenting with Lvalue Subs
by fergal (Chaplain) on Jan 24, 2005 at 23:39 UTC
    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]

        He is saying that it would make it impossible to do things like (in spirit)

        local $foo->bar = 'baz';

        [download]

        ie dynamic scoping. If the sub was responsible for the actual assignment, this would be impossible because it can't know whether the assignment is scoped dynamically and because there is no obvious mechnism for undoing the assignment at the end of the block. If you require validating to go through a tied proxy object, all of this is trivial since all the existing language hooks work as expected.

        Makeshifts last the longest.

[reply]
[d/l]

In Section Meditations