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:
Paul Johnson
Date:
March 7, 2011 16:09
Subject:
Re: Revising Perl's OO docs - a new OO tutorial
Message ID:
20110308000917.GU7931@pjcj.net
On Mon, Mar 07, 2011 at 06:05:26PM -0500, Chris Prather wrote:
> On Mon, Mar 7, 2011 at 4:21 PM, Ricardo Signes
> <perl.p5p@rjbs.manxome.org> wrote:
> > * Chris Prather <chris@prather.org> [2011-03-07T15:21:44]
> >> 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.
> >
> > He didn't say that it would have to be lvalue subs.
> 
> I didn't mean to either. I added them as a second data point. I see
> how bringing them into the argument at all could be confusing.
> 
> > Look at how Ruby does this:  you provide an "attr=" method that is called on
> > assignment, so you are not violating encapsulation or confusing behavior with
> > state.  It's sugar for a normal method call, which can have any behavior you
> > want and mutates whatever state system it wants however it wants.
> 
> I can't argue the merits of Ruby's implementation. It's not one of the
> languages I've paid attention to enough to know how it's behavior
> works here other than a cursory glance (during our conversation on
> IRC) that suggests it behaves the way I would expect.
> 
> In the paragraph you cited though, I'm not arguing about the
> implementation. I'm arguing about the semantics of the syntax.
> 
> > I'm not saying that I want ->attr=$x, only that you are arguing against
> > something that needn't be true.
> 
> In my opinion you're moving from dangerous to useless at best. I feel
> that the *semantics* of this syntax are confusing. They confuse method
> dispatch with assignment*. To me it's a dangerously short step from
> $obj->attr = $x; to $obj->{attr} = $x; where you drop the
> encapsulation entirely. Suggesting that encapsulation is a bad thing,
> or even an undesirable thing is the "horrible idea". Especially for
> the beginners that the advantages of a $obj->attr = $x syntax would
> primarily benefit.
> 
> * I recognize that this is intentional. This is one of the places I
> think TIMTWODI should bow to BSCINABTE at a syntactic level.

What is being discussed here is the "Uniform Access Principle".  Its
purpose is specifically to ensure that encapsulation is *not* violated.
See http://en.wikipedia.org/wiki/Uniform_access_principle

Perl6 was going to support it, and I believe it now does:
http://www.mail-archive.com/perl6-language@perl.org/msg09420.html

I would love to have a core OO system which supported this principle.

-- 
Paul Johnson - paul@pjcj.net
http://www.pjcj.net

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