On Tuesday, 20. October 2009 18:35:36 David Green wrote:
> >> So what the OP wants to do is declare a method that is available on
> >> all those invocants - and only those invocatnts - which do all of
> >> roles X, Y, and Z. Granted, you can declare a new role XandYandZ
> >> that does X, Y, and Z, and define the method there, but that won't
> >> work on $foo unless you declare explicitly '$foo does
> >> XandYandZ' . The goal is to have the method show up no matter how
> >> $foo comes to do all three roles.
I have difficulty seeing the need for a method here. The distinguishing
feature of a method is the access to the private data of an object that
can hardly be granted by doing the three roles X, Y and Z. After all
there's no unique implementation of these roles!
Perl 6 is a hybrid language as far as dispatch is concerned. There is
the class based method dispatch that I call slot dispatch because the
usual implementation is to have the objects carry a ref to a slot table.
The other dispatch is the type based MMD. Unfortunately this also
goes by the name of method. This is because other languages use classes
as types and conflate the two dispatch regimes that Perl 6 clearly
separates. There used to be fail-over from class dispatch to MMD but
this didn't work---even though I forgot what the exact problems were ;)
So in the end the only problem is that the calling conventions of
$object.method versus method($object) are not interchangeable. But
it makes the priority clear. In the $object.method case the object
is the primary concept. We think of it as the object doing something.
In many cases to its own state. In the method($object) case the method
is the primary concept. The object influences how it is done or what
is the output. The method can of course call mutating methods on the
object but this is a secondary concern.
"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