A tale about accessors, lvalues and ties

[LanX]

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;

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

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

[jettero]

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.

[LanX]

>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;
}

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
}

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

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

[perrin]

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.

[LanX]

Maybe a misunderstanding, this discussion is intended for those who prefer the flexibility of accessors and are in favour of the neat syntax of lvalues.

Me, I certainly don't want to get into any direct access discussion.

UPDATE: I suppose with "direct access" something like $obj->{attr} is meant.

UPDATE2: Anyway I already studied this Experimenting with Lvalue Subs, but couldn't find a discussion about speeding up tie, only about reimplementing lvalues.

UPDATE3: Let's try to collect some threads:

• Experimenting with Lvalue Subs
• Are lvalue methods (as properties) a good idea?
• To Validate Data In Lvalue Subs
• Tie Me Up, Tie Me Down
... to be expanded

searchquery: ?node_id=3989;BIT=%27%20lvalue%20%27%20tie%20%27;BIS=%20%27

[perrin]

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"?

[LanX]

maybe someone is interested in (or wants to verify) my benchmark hack:
Read more... (4 kB)

[Anonymous Monk]

Is this a question or a meditation? Maybe the thread should be transferred!

[LanX]

How? Can't find any hints on the helppages...

[Anonymous Monk]

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