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.