On 10/6/06, TSa <[EMAIL PROTECTED]> wrote:
HaloO,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 this: 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 perspective.
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 http://www.jot.fm/issues/issue_2004_01/column4
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 information!
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. - Stevan
