HaloO chromatic,
you wrote:
I don't understand the question (I don't recognize the words "lubs" or "glbs", for example), but I don't think this has anything at all to do with multiple inheritance.
Sorry, that was given only in the picture: lub = least upper bound (also known as supremum) glb = greatest lower bound (infimum) see e.g. http://www-rohan.sdsu.edu/~gawron/mathling/poset/posets.pdf
I don't think that roles are necessarily unsubstantiable; class and role names should occupy the same namespace.
That is the case in Perl 6, isn't it? Makes sense to me. And subs are in the same name space as well, right?
It ought to be possible to have class A with a particular set of methods and class B with a set of methods of the same name and similar enough semantics for the entire set of behavior of those methods and be able to mark class B as performing the A role
Hmm, like that?
class A { ... }
class B does A { ... }and to be able to pass B objects into code that asks for A objects and have things just work without A or B necessarily having to share code and definitely without them being related to each other in any sort of inheritance relationship.
Types/roles and classes form different hierarchies. The former is partially ordered by checking the does relation the latter by checking the isa relation. By letting classes do roles you create families of objects that do a certain behaviour but don't share the same implementation. On the other hand areas of code happen to require certain functionality. The entity that checks that they are met is the typechecker. My question basically is about how you declare your intensions so that the type checker can DWYM. E.g. if you were to specify comparability so that you are just comparing the right things.
Maybe there's not enough behavior in a role to make it a full class, but there's enough behavior that it's useful across classes horizontally and it deserves its own name.
My question is not about completeness of roles versus classes but about how the Perl 6 type system shall work. Or better which assertions it is supposed to make about code. This is very usefull when it comes to programming in the large and of course it allows good optimization if the typecheker can proof e.g. that no dynamic dispatch is needed because there is only one statically determinable match anyway.
Maybe that's not helpful, but I did warn that I didn't understand the question!
I'm struggling, too. -- TSa (Thomas Sandlaß)
