On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote:
: Personally, .foo meaning $self.foo seems more consistent to my mind, and 
: I'd happily standardise on implicit invocants.

I'm thinking about it.  There are definitely things to be said for both
sides, and maybe we can come up with a solution that's better than what
we have.  And after all, I originally came up with the .foo notation
precisely for the purpose of leaving out $self and still having it
self-documenting, as it were.  I have a vague feeling that the real
linguistic thing going on here is that you shouldn't change the meaning
of "it" within a method, so one possible solution would just be to
prohibit any rebinding of $_ to anything other than the current object.

In that case we'd have to say that "given" and "for" always require
"-> $x" inside methods, and that $x is never automatically aliased
to $_.  But there are other ramifications with switch statements and
exception handlers I have to think through, and I'm a slow thinker,
and unfortunately I'm having to moonlight at a real job to put bread
on the table and pay back all the money I've borrowed over the last
several years in order to devote myself to Perl 6--so you'll all just
have to be patient with me.  Well, you don't have to, but it'd be nice...

: The only minor thing I 
: can see would be that you will end up with a slight asymmetry question 
: of "if we use $:attribute for a private attribute, do we call :method 
: for a private method?"

I think those would still be .:method, and we just live with the
asymmetry, unless we decide there's sufficient declarational power
in the class that we can always distinguish :method from :pairkey,
which there might be.  But even if there is, most uses of private
methods will probably be from within trusted classes, and access to
my own attributes through $:foo instead.  Plus .:method doesn't require
people to remember what's been declared to decide if it's a pair
or a private method.


Reply via email to