Front page | perl.perl6.language |
Postings from October 2006
HaloO, Stevan Little wrote: > 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. I don't get that. The type system would give compile time errors. The current spec means that in case of a "conflicting" method the class version simply overrides the role version. That is there is simple, short or long name based "conflict" checking with priority to the class. > > I see that quite different: roles are the primary carrier of type > > information! > > Well yes, they do seem to have taken on this role ;). If it is not roles that carry type information then the Perl6 type system is as of now completely unspecced. Even with roles I miss some clear statements about their theoretical background. > 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). Remember the paper did not include state for traits and thus nicely avoided several typing issues particularly in SmallTalk that is based on single inheritance and dispatch along these lines. > 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. My current understanding is that properly typed roles can obliviate the need of the things described in theory.pod and directly go with F-bounded polymorphism as the theoretical model of the type system. It e.g. is strong enough to model Haskell type classes. Note that there are free mixins that pose no requirements on the class in the theory as described in the article. > > Dispatch depends on a partial ordering of roles. > > Type based dispatch does (MMD), but class based method dispatch > doesn't need it at all. I strongly agree. The two hierarchies should be separated. The only interweaving that occurs is the class composition process. And this process should IMHO be directed by the type system and provide for method combination when the correct typing of the role requires it. Typical examples that need method combination are equality checking, sorting support and generic container types. There seems to be another connection from the class hierarchy to the role hierarchy that is that a class has a role of the same name so that class names can be used where a type is expected or however this is supposed to work. In the end there shall be some mixing of class and type based dispatch or some kind of embedding of the class dispatch into type dispatch. > 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. But how else do we define a subtype relation if not through a role type lattice? > Possiblely we should be seeing roles as a way of *implementing* the > types, and not as a core component of the type system itself? Hmm, again what is the type system then? All indications from the Synopsis and this list go for roles taking over the responsibility of key player in the type department. E.g. type parameters also go with roles not with classes. Regards, --Thread Previous | Thread Next