develooper Front page | perl.perl5.porters | Postings from March 2011

Re: Revising Perl's OO docs - a new OO tutorial

Thread Previous | Thread Next
From:
Chris Prather
Date:
March 7, 2011 12:21
Subject:
Re: Revising Perl's OO docs - a new OO tutorial
Message ID:
AANLkTinnosRQxVStS0tzBKAme6T4dAEkD5ytEoU=MhcE@mail.gmail.com
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.

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.

-Chris

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About