develooper Front page | perl.perl6.language | Postings from May 2005

Re: ./method

Thread Previous | Thread Next
From:
Larry Wall
Date:
May 15, 2005 18:01
Subject:
Re: ./method
Message ID:
20050516010121.GD26184@wall.org
On Sun, May 15, 2005 at 08:54:52PM -0400, Matt Diephouse wrote:
: Damian Conway <damian@conway.org> wrote:
: > Larry Wall wrote:
: > 
: > > On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: > > : Does this mean private methods will be called like this?
: > > :
: > > :   ./:method()
: > >
: > > No, I think that's still just
: > >
: > >     .:method()
: > 
: > This missing design rationale here is that the colon acts as part of the unary
: > operator:
: > 
: >      ./    unary public-method-call-on-invocant
: > 
: >      .:    unary private-method-call-on-invocant
: 
: This introduces some asymmetry with accessors, which are currently
: $.attr and $:attr. I think in this case it's more consistent to use
: the $/attr for public attributes. Unfortunately, I find that rather
: ugly, which is why I gave up trying to find a secondary sigil for
: public methods called on the invocant in the first place.
: 
: In other words, I don't see any solution here that is less than ideal.

I think almost all internal access to one's own attributes will be
via $.foo and $:bar.  Outside the class there is already a complete
asymmetry between public and private methods, so there's no reason to
invent a perfect encoding for the few cases where it matters.  $.foo is
good enough to indicate that there are probably external methods,
and $:bar is good enough to indicate that there probably aren't.

Larry

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