Luke Palmer wrote:
On 10/29/05, Damian Conway <[EMAIL PROTECTED]> wrote:

So we need a mechanism that is externally (i.e. from a class interface
point-of-view) a subroutine, but internally has the features of a method (i.e.
has an invocant). Since it's externally sub-like but internally method-like,
we call this useful construct a submethod.

Wouldn't the semantics fall out naturally from
1) beeing a scoped 'our sub'
2) the topic type ^_ of the topic item $_ beeing
   contra-variantly defined to the concrete class type?

Number 1) assumes that a sub definition in a class without my or our gets
a sig of :(Any $_ = CALLER<$_>, [EMAIL PROTECTED]). The property 2) ensures the
non-inheritance indirectly because an overriding sub in a derived class
would permit the Foo::bar application.

That is Luke's example could read

  class Foo
     has $.data; # creates rw accessor
     our sub bar # sig is :( void: Foo $_, [EMAIL PROTECTED] )
        $.data = 23; # Not allowed outside of class scope?
      #  .data = 23; # Or force through accessor?

  my $foo = Foo.new;

  $foo.bar;  # binds $_ := $foo and all member refs through $foo,
             # then calls Foo::bar with empty @_

  say $foo.data;  # prints 23

For most of that, doesn't a private method suffice?

When it doesn't, I feel uneasy about:

    class Foo {
        submethod bar() { ... }
    my $foo = Foo.new;

If that's externally sub-like, why does it look so much like a method?

Isn't looking like a method more a feature of the dot syntax than anything
else? Does bar($foo) cause the same perception? If my signature assumptions
above are correct then an argumentless bar call without "invocant" is a
"too few arguments" error.

If I understand the term 'package dispatch' of Sam Vilain correctly the
package that contains class Foo would maintain a dispatch into class scoped
subs depending on the immediate class---is that the eigenclass?---of the
"invocant". That is we could define

  class Bar
     has $.data; # creates rw accessor
     our sub bar # sig is :( void: Bar $_, [EMAIL PROTECTED] )
        $.data = 42;

in addition to the Foo from above and then

  sub package_dispatched ($x) { $x.bar }

  my $bar = Bar.new;

  package_dispatched( $foo ); say $foo.data; # 23
  package_dispatched( $bar ); say $bar.data; # 42

But I can understand that Damian thinks that spelling 'our sub' as
'submethod' is good documentation and not a subtlety. OTOH, a 'my sub'
is not considered too subtle. Actually a 'has sub foo ...' form might be
an alternate spelling for 'has &.foo = sub ...' and we can drop the
strange word 'submethod' and nicely unify all code types. That is

        sub = package dispatch on void
     method = unary dispatch on single invocant item type
      multi = symmetric multi dispatch on invocant tuple type
              or left biased successive single dispatch on invocant list
              or a mix of both

Reply via email to