Re^5: Are lvalue methods (as properties) a good idea?

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.

Comment on Re^5: Are lvalue methods (as properties) a good idea? Download Code

Replies are listed 'Best First'.
Re^6: Are lvalue methods (as properties) a good idea? by BrowserUk (Patriarch) on Jan 13, 2005 at 18:13 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^6: Are lvalue methods (as properties) a good idea?
by BrowserUk (Patriarch) on Jan 13, 2005 at 18:13 UTC

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.

[reply]