As Ovid once put it:

Of course, some lvalue fans argue that I can use tie to get my validation back. Great! Now I've lost much of the conciseness I've hoped to gain and I've probably moved the data validation code away from the method in which the maintenance programmer expects to see it but at least I've switched to a slow, confusing and fragile interface!

-sauoq
"My two cents aren't worth a dime.";

Ovid's beating a straw man in that quote. Nobody is suggesting that everyday you should bash out lots of awful code directly involving tieing. Would yourself and Ovid also object to exporting values and functions because it involves advanced symbol table poking? Of course not, it's all hidden behind Exporter. Most users don't know how it works at all.

The same goes for lvalue+tie. As I said in another post there's Class::Accessor::Lvalue. Personally I use my own home brew module which lets me say

package Circle;

use Fergal::MM qw( Radius Area );
# this creates
# setRadius, getRadius, Radius
# setArea, getArea, Area
#
# All are created in Circle::Accessors and Circle's @ISA
# is updated to include Circle::Accessors.
# This makes overriding easy.

# now override the Area ones
sub setArea
{
  my ($self, $area) = @_;
  $self->Radius = sqrt($area/PI);
}

sub getArea
{
  my ($self, $area) = @_;
  my $r = $self->Radius;
  return PI * $r * $r;
}
[download]

This removes all but one of Ovid's complaints - it's probably slow but if you really need speed then you can just ignore the lvalue interface and use the set/get methods directly. I think I benchmarked it as a factor of 10 slower but how much of your code is accessor calls? If you really need speed, Perl OO is probably not what you want.

My summary: lots of needless complexity for little or no real gain. I object to that. Strongly. It's not good enough that you can do it. Why would anyone want to? I don't agree, by the way, that what you've shown removes "all but one of Ovid's complaints" but say we take that to be the case. What about the remaining issue? Why would I want to leave bits of a redundant API around with the caveat that, if performance is an issue, they shouldn't be used?

-sauoq
"My two cents aren't worth a dime.";

C’mon now, what do you expect me to say? Don’t use Perl5 OO? :-)

Wait. Perl6 is right around the corner.

Or maybe… Have you heard of Ruby?

Seriously, though, things like Tie::Constrained take most of the pain away. Sure, I’d rather there was a better way, too. In any case, as a user of APIs with lvalue accessors I quite liked them; I haven’t so far actually designed an API with lvalue subs myself, however.

Basically, the ugliness involved in lvalue accessors is just one more thing that makes me go “okay, I have appreciated the beauty and elegance in Perl5’s ultra-minimal OO approach enough, but now I’d like to get some real work done.”

But all these considerations apply to the hidden end of an API. From the public side, lvalue accessors have no downsides whatsoever. They don’t expose anything untoward. That’s what I was arguing.

Makeshifts last the longest.

I was going to /msg you with "and don't use tie" but you beat me to it.

You return a tied value. Ugly, slow, and doable.

Why then would I ever have a need to go back and avoid lvalue subs?

Perhaps when you decide you need validation without an ugly and slow (but doable) implementation?

-sauoq
"My two cents aren't worth a dime.";