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. Larry
