I'm at a loss to see how this is preferable to:

Juerd has a node that demonstrated this nicely, but I cannnot find it right now. Compare:

$obj->bar++;

$obj->bar =~ s[a][b]g;

$obj->len++ while substr( $obj->bar, $obj->start, $obj->len ) =~ m[^\s
++$];
substr( $obj->bar, $obj->start, $obj->len, '');
$obj->len = 0;
[download]

with:

$obj->bar( $obj->$bar() + 1 );

my $temp = $obj->bar();
$temp =~ s[a][b]g;
$obj->bar( $temp );

my $temp2 = $obj->len;
my $temp3 = $obj->bar;
$temp2++ while substr( $temp3, $obj->start(), $temp2 ) =~ m[^\s+$];
substr $temp3, $obj->start, $temp2, '' );
$obj->bar( $temp2 );
$obj->len( $temp3 );
[download]

Another way of looking at it. Would you prefer doing math like this?

## $a++;
$a( $a() + 1 ); 

# $b *= $c-- $d++;
$b( $b() * $c( $c() - 1 ) % $d( $d() + 1 ) );
[download]

I'd say that syntactic sugar is pretty sweet! The $obj->bar( $obj->$bar() + 1 ); thing is really ugly.

I don't validate the contents of most of my getters/setters anyway, and for those I do, maybe I can live with the performance hit.

What turns me away most is the future proofing, i.e. what if I some time want to something inside the setter that becomes difficult or ugly with the limitations an lvalue sub brings?

All in all, I'm still in the undecided camp.

/J

I agree on both counts.

Ever since I first played with lvaue subs, I've both recognised the desirability of their clean syntax, and the limitations of their implementation.

I've also played with various fixes, including tieing the attributes, which is the best, if somewhat slow solution.

But then again, I also sit in that camp of people who believe that, for the most part, good OO design tenents preclude the use of (externally visible) setter and getter methods. That doesn't mean I always achieve that ideal, nor even try, but I believe that it is a tenant worth pursuing for important classes.

The only legitimate exception being their use internal to a class only. Having setters and getters to isolate the majority of the object code from it's internal data representation is a good idea. In this role, Lvalue subs/methods are ideal. If they are only used from within other (usually externally visible) methods, then those methods do all the verification of their input paramaters and when they use the lvalue mutators, the values passed have already been validated.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

I like the ability to use objects (and thus functions which return objects) as lvalues. A bit of my old C++ days sneaking up on me. But I won't use that until Perl6 when you can actually set a function to be the "set" routine, and a function as the "get" routine. I like the syntax of $obj->foo = 3, but I definitely need to be able to easily (that is, with little overhead) trap that to do something else with it - whether that's validate the new value, set a marker for change (that represents a dirty object for persistance), or send out events to listeners. Or even, heaven forbid, change my underlying object such that foo now represents something else. About the only thing I like about Perl 5's lvalue attributes is that they were something that taught Perl6's designers what was really needed :-)

Sure it's overhead. But you only need to write the tieing class once globally, and you only need to write one validating closure per kind of validation. With that work out of the way, you can define the constraints for all your attributes declaratively.

As far as I'm concerned it's a big win in terms of syntax and maintenance.

Makeshifts last the longest.