in reply to Re^7: can sub check context for lvalue vs rvalue context?
in thread can sub check context for lvalue vs rvalue context?

I don't need to return a constant under any circumstance, but if I know I am returning an rvalue, I can return: 
p->{_path}

[download]
If something is being assigned to 'path', then I'd know I need the lvalue -- and return something like 
$p->{tied_path}

sub callback_for_STORE_into_tied_path { my $p=shift;
  my $newvalue;
  $p->{_path}=$newvalue;
  $p->{_url}=undef;
  ...
  $p->{_path};
}
...later...in 
sub url(;$) { my $p=shift;
  $p->compose_url_from_parts() unless defined $p->{_url};
  $p->{_url}
}

[download]
So if someone want to read path, they would get a simple, direct reference (no tied var overhead), but if they wrote to it, it needs to store the new value, and clear the internal value for _url so it can be re-composed.

At no point should I need to return a constant -- just a choice between the actual var in the hash, or a tied var.

If I knew the lvalue-context, is there a reason why that wouldn't work?

Replies are listed 'Best First'.
Re^9: can sub check context for lvalue vs rvalue context?
by BrowserUk (Patriarch) on May 10, 2018 at 22:51 UTC
    I don't need to return a constant

    You miss the point entirely. (I beginning to wonder if it is deliberate.)

    If you return anything that is not an lvalue, it is a constant. The very definition of rvalue, is "unassignable". Perl won't let you do that.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]
      I get your point, but I appear to be missing it because I'm never returning an rvalue. In the sample usage I've listed, I'm not using any rvalues: it's always returning the *actual var*, OR a *tied var* -- both are lvalues, but in non-lvalue context, I can return the variable directly in the belief that it is not being modified or assigned to. 
      $p->{_url}  # simply var access (no tied usge)

      [download]

      In the lvalue case I would need to return a more expensive case, like: 

      $p->{_tied_url}

      [download]
      So I can do post-assignment-processing.

      It's a matter of optimization/performance -- not function.

      Are we on the same page yet?

[reply]
[d/l]
[select]
        but in non-lvalue context, I can return the variable directly in the belief that it is not being modified or assigned to.

        Your belief is wrong. In order for Perl to determine if the lvalue you return is ever modified, it would have to trace every usage or reference or alias of that variable right through to the end of the program.

        Eg. 

        sub x :lvalue { ...; $lvalue }
...

$y = this( $_ ) ? that( $_ ) : tother( $_ ) for x();

        [download]

        You may think that is too elaborate an example that will never come up; but to be useful, your wantlvalue() would need to handle that and every other possibility.

        Even the 'simple case', of somefunc( x() ); conceals the fact that the lvalue returned by x() is aliased, and within somefunc() could be passed on to still more code as an alias or reference.

        For your "belief that it is not being modified or assigned to" to have any validity, Perl would need to follow every possible path to the end of the program before it decide whether to return true or false from wantlvalue().

        Imagine the lvalue (or an alias or reference to it) is used in a conditional statement inside a loop; that could be dozens (hundreds/millions) of different possible paths, any of which might modify it.

        It would be impossible for a dynamic, interpreted language to provide an "is never modified" guarantee.

        And that's before you consider the possibility that an alias or reference to your lvalue might be used as part of a piece of run-time constructed code that gets eval'd.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]
[d/l]
[select]
        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.

[reply]

In Section Seekers of Perl Wisdom