HaloO,
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;
$foo.bar;
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
--
