HaloO,
Larry Wall wrote:
Although, interestingly, if the method is exported as a multi it
should automatically add in the current role or class as a constraint
on the (former) invocant so that multi dispatch will not overgeneralize.
I would expect
class Foo
{
method bar {...}
}
to give &bar the signature :(Foo $:). What else? And why?
And putting a type in
class Foo
{
method bar (Baz $self:) {...}
}
should actually result in the sig :(Foo Baz $:), that is the type
Baz is just an additional constraint. But that is already very
strange. But then a completely alien self type is even more strange.
One big subject in OO type theory is the self type. E.g. when a
method is inherited some languages like C++ and Java keep the type
of the invocant at the base level. Perl 6 does a better job here
because every method is virtual in the C++ sense. That is any method
is dispatched. But access to the object data is a different matter.
Perhaps it should do that only if the invocant is untyped, in which
case typing the invocant to Any might make sense for multis that want
to go into Any. But if that's the case, we should also alias the
method itself into Any as a method, probably. Not sure what that buys
us, apart from possibly keeping the Any class cleaner. But then it
smells a bit more like monkey typing if (Any $self:) adds the method
into Any after the fact. Not exactly sure when "the fact" is, though. :)
I know that the use of 'is also' is called monkey patching but I can't
understand why this is regarded as a bad thing. Having a class assembled
from multiple modules is a rather normal affair. I would also add more
syntactic relieve e.g. for single methods outside of class bodies.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
