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

fergal,
Have a look at...

*Chuckle* One of the first points I made was that instead of fixing the implementation of Lvalue subs, people chant the mantra:

If we are going to revert to other wheels, I personally prefer Attribute::Property and even discussed how to overcome some of its limitations. It doesn't fix the fact that a core feature is pretty much unuseable in the current form.

As for getting the rvalue, it's possible but it's not pretty!
Not really. I already mentioned that tying is the last ditch effort in the mantra and I am well aware of how to do it. The trouble is that you are not getting at the rvalue inside the sub which makes tying necessary. The point of the meditation is to spark interest in correcting this deficiency, not more work arounds.

Unfortunately I am not a competent C programmer, but TimToady indicated elsewhere in this thread that he wasn't opposed to the change as long as it was in alignment with p6. And all this time I was assuming the trouble would be with getting it past p5p not the patch itself.

Cheers - L~R

Replies are listed 'Best First'.
Re^3: Experimenting with Lvalue Subs
by fergal (Chaplain) on Jan 24, 2005 at 23:29 UTC
    Indeed, sorry for not reading more carefully. However my comment isn't entirely void, have a look at Apocalypse 6 where Larry says that lvalue subs will not get to see their rvalue unless they use tieing
    If you need to do pre- or post-processing on the "public" value, however, you'll need to return a tied proxy variable.
    and he also said that the tieing will be easy. He has other plans (temporizing - basically a tie interface to local) that would break if it was done the way you want.

    There's still also the issue of potentially surprising order of evaluation.