Front page | perl.perl5.porters |
Postings from March 2011
On Mon, Mar 07, 2011 at 03:21:44PM -0500, Chris Prather wrote: > On Sun, Mar 6, 2011 at 9:34 PM, Father Chrysostomos <sprout@cpan.org> wrote: > > If we do add object attributes to Perl, it would be very nice if we could use ‘$obj->attr = $foo’ syntax, instead of $obj->attr($foo), which is currently widely used mainly because the former is so hard to do (that can change, of course). > > > > It's my (not-so-humble) opinion this is a horrible idea. It violates > encapsulation and confuses the behavior with state in a way that will > only lead to *more* confusion down the line. The public API for a > class should rarely if ever expose the implementation details. > Specifically as a consumer of a Class I should never care if a given > behavior is implemented as an attribute or a method. Unfortunally, that's how many people see objects: a bag of attributes. And that's the motivation for at least half the "OO frameworks" out there, "to save typing on when creating accessors". IMO, Perl already has an excellent datastructure to handle bags of variables/attributes. It's called a hash. > With this perspective all lvalues do is create a special case method > invocation that only accepts a single parameter. This means that you > add unnecessary complexity into your API by meaning that you have to > remember (or look up) which methods get called in the traditional way > ( $obj->foo(@param) ) and which are called in the special "we wanna > look like a state change" way ( $obj->foo = $param ). > > Add in the current "finicky" nature of lvalue subs (that you can't > perform runtime type checking, nor can you use the 'return' keyword) > makes lvalue methods actively dangerous in a code base. Fixing the > finicky parts would move them from "dangerous" to simply useless. Indeed. AbigailThread Previous | Thread Next