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
