Re^11: can sub check context for lvalue vs rvalue context?

I agree with both of you.

Yes you are never returning a read only value.

But as BUK demonstrated the caller could take a reference* and assign later.

In this case your logic would break without a protecting tie.

Anyway did you benchmark the impact of a tie?

IIRC does a tied variable without FETCH method fall back to a normal read.°

Not sure about the resulting performance penalty.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)

Wikisyntax for the Monastery}

*) Your WANTLVALUE would need reflect this too, like in an extra state "referenced".

°) looks like I was confusing the semantics of Tie::Scalar (with a fallback method) with a normal perltie on scalars, where FETCH must be defined.

Comment on Re^11: can sub check context for lvalue vs rvalue context?

Replies are listed 'Best First'.
Re^12: can sub check context for lvalue vs rvalue context? by perl-diddler (Chaplain) on May 14, 2018 at 03:53 UTC
This idea of a reference to an lvalue violating the logic inside the object is very confused. The reference is a reference to an OBJECT. When you dereference the reference, THEN you access the object which can look at context to see if it is being assigned to or not. My lvalue object, is not entered and the code in it is asleep when you take a reference to it. This is the whole reason for wrapping things in an object. While you can pass a reference around or create an alias -- no matter. It's only when you try to assign to the object (the dereferenced thing) OR read from it that the decision code inside the object would look at the return context to see if it is really being modified or is being used in an rvalue context and return a more expensive or cheaper version. Upon assignment to my object (through references or aliases), I store the new value and do the post processing -- all within the object, then it returns. So no logic is broken unless someone opens up the object and starts calling internal functions or changing internal values. If I'm way off base, please explain it to me, as the way I see it is, for this code: `my $ref = \x(); ## lvalue context, no assignment. ... some time later assign through the ref taken. $$ref = 'anything at all';` [download] There's no magical getting around `'X()'` which isn't called until dereferencing `'$ref'` w/`'$$ref'`. The dereferencing is really doing `${\x()}`, which calls `x()` at the time it is dereferenced (accessed). Only in that final context would it detect if it is being assigned to or not. Haven't benched-marked anything as I'm trying to figure out a way to not implement it using 'tie' that doesn't allow for optimization. So far, the `magic::variable` is the most likely candidate as it seems to have a post-store phase where I can update related variables.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^12: can sub check context for lvalue vs rvalue context?
by perl-diddler (Chaplain) on May 14, 2018 at 03:53 UTC

The reference is a reference to an OBJECT.

When you dereference the reference, THEN you access the object which can look at context to see if it is being assigned to or not.

My lvalue object, is not entered and the code in it is asleep when you take a reference to it.

This is the whole reason for wrapping things in an object. While you can pass a reference around or create an alias -- no matter. It's only when you try to assign to the object (the dereferenced thing) OR read from it that the decision code inside the object would look at the return context to see if it is really being modified or is being used in an rvalue context and return a more expensive or cheaper version.

Upon assignment to my object (through references or aliases), I store the new value and do the post processing -- all within the object, then it returns.

So no logic is broken unless someone opens up the object and starts calling internal functions or changing internal values.

If I'm way off base, please explain it to me, as the way I see it is, for this code:


my $ref = \x(); ## lvalue context, no assignment.

... some time later assign through the ref taken.

$$ref = 'anything at all';
[download]

'X()'

'$ref'

'$$ref'

The dereferencing is really doing ${\x()}, which calls x() at the time it is dereferenced (accessed). Only in that final context would it detect if it is being assigned to or not.

Haven't benched-marked anything as I'm trying to figure out a way to not implement it using 'tie' that doesn't allow for optimization. So far, the magic::variable is the most likely candidate as it seems to have a post-store phase where I can update related variables.

[reply]
[d/l]
[select]