I'd have to agree. I also think that .foo should always mean $_.foo in methods, without causing any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of "legacy" in the Perl6 language. OK - As I understand it, this is what A12 says: class Foo { # normal instance variables has $.x; has $.y is rw; has $:z; has @.foo is rw; has @:bar has %.baz is rw; has %:ber method one { return 1 } method :two { return 2 } # some class variables our $.class_var1; our $:class_var2; our $.class_var3 is rw; my $.class_var1_visible_only_to_class; my $:class_var2_visible_only_to_class; # implicit object set in $?SELF method grr { $.x = 1; $.y = 2; $:z = 3; push @.foo, 'item'; push @:bar, 'item'; %.baz<key> = 'val'; %:ber<key> = 'val'; my $a = .one; # hmmm - here is the subject of all of our pain my $b = .:two; } # explicit object method roar ($obj:) { $.x = 1; $.y = 2; $:z = 3; push @.foo, 'item'; push @:bar, 'item'; %.baz<key> = 'val'; %:ber<key> = 'val'; my $a = $obj.one; my $b = $obj.:two; } } # external use of object sub squawk ($obj) { $obj.x = 1; # fails - no accessors $obj.y = 2; # ok - lvalue accessor was created for us because of "is rw" $obj.:z = 3; # fails - no public accessors - even if "is rw" push $obj.foo, 'item'; # ok - lvalue accessor created push $obj.bar, 'item'; # fails - even if "is rw" $obj.baz<key> = 'val'; #ok - lvalue $obj.ber<key> = 'val'; # fails - even if "is rw" my $a = $obj.one; my $b = $obj.two; } Somebody correct me if I had things wrong up above. So in all of that example, all of the instance variables and methods are easily accessed and almost all of the rules are clear cut. So under this "final" proposal we now have the following: class Foo { has @.elems; method rock { .wizbang; # called on $?SELF - looks ambiguous (what is $_) .foo for @.elems; # fails with an error - ambibuous compared to .wizbang } method stone ($obj) { $obj.wizbang; .foo for $obj.elems; # supposedly fails ($_ no longer =:= $?SELF) :( } } sub conglomerate_solid ($obj) { $obj.wizbang; .foo for $obj.elems; # ok here } sub petra ($obj) { temp $_ = $obj; .wizbang; .foo for .elems; # confusing - but ok (called on different objects) } I don't think the most recent proposal (er edict) is really all that friendly. I've been hoping that it is a case of linguist/architect/benevolent president turned psychologist and that it is a "foot in the door approach" of getting both sides of the ./method argument to just give up and be quiet. This latest proposal seems to add ambiguity all in favor of getting rid of a slash. Looking at all of the instance variables and method accesses in the method "grr" up above, a method call of "my $a = ./one really isn't that out of place. Once the object is explicit, then all method calls change (including the private ones) while all of the instance variables stay the same. I think that .method == $_.method needs to always hold true. I still think it would be nice - though not as important to have ./method (or whatever variation you want) work inside methods. I don't think that $_ should ever default to the invocant ($_ =:= $?SELF) (which should be easy enough with "method a ($_) { ... }"). method concrete { ./wizbang; .foo for @.elems; .foo for ./elems; # possibly odd looking - but not confusing } Please, lets pick something sane. Here I go speaking for the list, but I don't think we will find many that think ".method syntax breaks in methods if $_ is rebound" as a very sound concept. Paul