Stevan Little wrote:
The concept of non-inherited infrastructural methods is fairly simple to
accomplish in the meta-model, by just giving submethods their own
dispatch table inside the metaclass. However where I am somewhat
confused is in how and when they get called.
I think the question is posed a bit confusingly. Since as you point out,
when the invocant is clear, calling the (sub)method is an easy lookup in
its vtable with subsequent call.
Take this example for instance:
class Foo {
method bar () { ... }
submethod bar () { ... }
}
Is this an error (Synopsis 12 seems to indicate it is *not* an error)?
The only inconvenience I see is that the name Foo::bar is not unique.
The sigil doesn't disambiguate because in both cases it is &Foo::bar.
Furthermore the :() is used only to distinguish different sigs, not the
Code subtype behind the name. Hmm, or is this a special cased two-entry
MMD table? One entry for &bar:(Foo) and one for &bar:(MetaClass[Foo])?
When I call bar() on an instance of Foo, which is called? The method? or
the submethod? Is it somehow dependent upon the calling context? (called
from within the class, or from outside the class). Take for instance,
this example:
class Foo {
method bar () { ... }
submethod bar () { ... }
method baz ($self:) {
$self.bar() # which one does this call?
}
}
I think this is pretty clear. There is exactly one class object Foo
but many instances. The submethod can only be called on the Foo class
object which is available through the .meta method. Thus to call
the submethod one needs $self.meta.bar(). I doubt the usefullness
of falling back to submethod lookup in the class chain when an object
doesn't have the method.
There's actually no syntactical distinction possible because of:
my $object = new Foo;
my $meta = $object.meta;
$meta.bar() # calls submethod but looks like method call
I guess the type of $meta is Ref of Class or somesuch.
Regards,
--
TSa (Thomas Sandlaß)
