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

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

Thread Previous | Thread Next
From:
Paul Seamons
Date:
July 15, 2005 13:55
Subject:
Re: WTF? - Re: method calls on $self
Message ID:
200507151455.36578.parrot@seamons.com
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About