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

Re: WTF? - Re: method calls on $self

Thread Previous | Thread Next
Paul Seamons
July 15, 2005 13:55
Re: WTF? - Re: method calls on $self
Message ID:
I'd have to agree.

I also think that .foo should always mean $ 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 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, '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, 'item';
     push @:bar, 'item';
     %.baz<key> = 'val';
     %:ber<key> = 'val';
     my $a = $;
     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 $, 'item'; # ok - lvalue accessor created
   push $, 'item'; # fails - even if "is rw"
   $obj.baz<key> = 'val'; #ok - lvalue
   $obj.ber<key> = 'val'; # fails - even if "is rw"
  my $a = $;
  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) {
      .foo for $obj.elems; # supposedly fails ($_ no longer =:= $?SELF) :(

sub conglomerate_solid ($obj) {
    .foo for $obj.elems; # ok here

sub petra ($obj) {
   temp $_ = $obj;
   .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 

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


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About