On 10/6/06, TSa <[EMAIL PROTECTED]> wrote:
Stevan Little wrote:
> As for how the example in the OP might work, I would suspect that
> "super" would not be what we are looking for here, but instead a
> variant of "next METHOD".
I'm not familiar with the next METHOD syntax. How does one get the
return value from it and how are parameters passed? Would the respective
line in the equal method then read:
return next METHOD($p) and self.x == $p.x and self.y == $p.y;
I think that a super keyword might be nice syntactic sugar for this.
I think super is not something we would want in Roles, it implies
ordering, which defeats the flattening aspect of Roles. IIRC the
syntax to call the next method with new args and a return value is
return call($p) and self.x == $p.x and self.y == $p.y;
However, I am not sure I really like the look of that myself.
> However, even with that an ordering of some
> kind is implied
The only ordering I see is that the class is "up" from the role's
But thats the whole problem, there is no "up" in roles, they are flattened.
When more then one role is combined and all require
the presence of an equal method I think the roles can be combined
in any order and the super refers to the class combined so far.
IOW, at any given time in the composition process there is a current
version of the class' method. The final outcome is a method WALK
or however this is called in composition order. Conceptually this
is method combination: seen from outside the class has just one
type correct method equal. Theoretical background can be found in
I do not think method combination should be the default for role
composition, it would defeat the composeability of roles because you
would never have conflicts.
However, I can see the possibility of method combinations in roles
being some kind of special case. How that might look from a syntactic
perspective I have no idea.
> I suppose this is again where the different concepts of classes are
> roles can get very sticky. I have always look at roles, once composed
> into the class, as no longer needing to exist. In fact, if it weren't
> for the idea of runtime role compostion and runtime role
> introspection, I would say that roles themselves could be garbage
> collected at the end of the compile time cycle.
I see that quite different: roles are the primary carrier of type
Well yes, they do seem to have taken on this role ;). However, roles
as originally envisioned in the Traits paper are not related to the
type system, but instead related to class/object system. In fact the
Trait paper gave it's examples in Smalltalk, which is not a strongly
typed language (unless you count the idea that *everything* is an
object and therefore that is their type).
I think we need to be careful in how we associate roles with the type
system and how we assocaite them with the object system. I worry that
they will end up with conflicting needs and responsibilities and roles
will end up being too complex to be truely useful.
Dispatch depends on a partial ordering of roles.
Type based dispatch does (MMD), but class based method dispatch
doesn't need it at all.
The whole fact that dispatching requires roles to be partially ordered
actually tells me that maybe roles should not be so hinged to the type
system since roles are meant to be unordered.
Possiblely we should be seeing roles as a way of *implementing* the
types, and not as a core component of the type system itself?
I did some experimentation with this in Moose::Autobox, but that is
for Perl 5 so I am not sure how relevant it is here.