LanX has asked for the wisdom of the Perl Monks concerning the following question:

Hi

In OOP it really bothers me to write use getter/setters instead of lvalues for simple attributes like in other languages.

As shown in PBP, the problem with lvalue is, that if ever you need a wrapper to control the setting of the attribute you can only rely on tieing the variable or you have to change the API and refactor...

Which is not really an issue of ugly syntax, I found at least two cpan-modules showing that a posteriori FETCH and STORE can be done in a very clean, readable and maintainable syntax. e.g. in Class::Closure

I did some benchmarks showing that accessing a tied variable via lvalue is 4-5 times slower than with a getter sub! : (

Now I "superfound" Re^3: Class::Accessor and Damian's PBP and was quite exited to see Contextual::Return...

So, very curious about how TheDamian fixed the problem, I took a look into the source: 

  $impl = tie $_[0], 'Contextual::Return::Lvalue',     
            $subname => $handler, args=>$args;

[download]

Do I get it right, it's just another sugar for Tieing? 8 (

Well I don't know how big the trade-off of wrapping lvalues is in other languages ...

But shouldn't this general "banning" of lvalues better be replaced by the rule

It's acceptable to use them as long you are aware that later changing will result in a call-overhead of 400%!

Time critical calls should be done with getter/setters!

???

BTW: Is there any activity to speed up tie? I don't see why the calling mechanism for FETCH and STORE needs to undergo the same slow dynamic ways OOP needs. A kind of "tie :static" might really solve the problem!

Hopefully looking for a serious discussion of this somehow "religious" matter..

Cheers LanX

- - - - - Which song???

UPDATE: fixed some typos, some English, some mark up ...

Replies are listed 'Best First'.
Re: A tale about accessors, lvalues and ties
by jettero (Monsignor) on Nov 18, 2008 at 14:14 UTC
    There's certainly plenty of places where perl has special parsing rules (e.g. defined(&func)).

    I think it'd be worth doing something, special parsing wise.

    On the other hand... Maybe they should just finish and make it so $object->attr = something would work correctly and allow implementers to actually usefully check the rvalues when they're of a mind to do so. It seems silly to go part way, then stop and say: don't use this.

    -Paul

[reply]
[d/l]
[select]
      >It seems silly to go part way, then stop and say: don't use this.

      Well it's "experimental" and adding new features into Perl 5 is for sure no fun. Dependencies across the code seem to form a gordian knot. I read once the main argument for Perl 6 is that Perl 5 is at the limits of extendibility. Another faster tie mechanism might be a hell of a work...

      But maybe there is another approach how to extend lvalue subs. I just realised that lvalue-subs are not limited on returning scalars, they can also return another lvalue-sub at the end: 

      sub normal :lvalue {
   proxy();
}
sub proxy :lvalue  {
   $anyscalar;
}

      [download]

      it might be interesting to see how this is realised on the level of op-codes and if proxy() could be realised externally, maybe as a c function!

      AFAIK it's possible with XS to call non-lvalue c functions from within perl. Maybe it's possible to write a module which realises a lvalue function named proxy() which takes coderefs for a STORE and FETCH routine and calls them internally on the to be wrapped variable. 

      sub normal :lvalue {
   proxy(\&store,\&fetch,\$var); # imported function
}

      [download]

      This interface wouldn't change anything in the code of the p5porters, but could be much faster than tie is!

      Maybe someone who knows more about opcodes and c extension might comment on this idea ...

      Cheers LanX

      UPDATE: The discussion continues here Analyzing opcodes of lvalue-subs...

[reply]
[d/l]
[select]
Re: A tale about accessors, lvalues and ties
by perrin (Chancellor) on Nov 18, 2008 at 18:25 UTC
    Direct attribute access is a pretty old OO discussion. You're welcome to look up the old arguments about accessors and whether they should always be used, but I can't see anyone coming up with anything new at this point. You just have to make your choice.
[reply]
[reply]
        Ok, your reference to needing a wrapper to control the setting of the attribute made me think you were talking about direct access. I'm definitely not a fan of lvalue subs or tie. Other than Ruby, are there any languages that support syntax like "object->method = value"?
[reply]
Re: A tale about accessors, lvalues and ties
by LanX (Saint) on Nov 18, 2008 at 16:00 UTC
    maybe someone is interested in (or wants to verify) my benchmark hack:
    Read more... (4 kB)

    Cheers LanX

    - - - - - Which song???

[reply]
[d/l]
Re: A tale about accessors, lvalues and ties
by Anonymous Monk on Nov 19, 2008 at 13:11 UTC
    Is this a question or a meditation? Maybe the thread should be transferred!
[reply]
      How? Can't find any hints on the helppages...

      Cheers LanX

[reply]
        Don't worry about it, it was approved and frontpaged by experienced monks (they think its fine in this section).
[reply]

Back to Seekers of Perl Wisdom