In a message dated Wed, 25 Oct 2006, TSa writes:
from the recent threads 'class interface of roles', 'set operations for roles' and 'signature subtyping and role merging' I wonder how typish roles actually are. Some seem to consider roles as lightweight particles that serve to compose classes. I see them as the heavyweights in the type department. Doing a role is like a contract about certain functionality. So, what does @Larry think?
I'll let @Larry speak for @Larry, but at one point I was told that when C<Array> or C<Hash> appear in signatures, those are roles, not classes; if you examined a particular Array or Hash, the class would be some implementation of the Array or Hash role, perhaps something like C<PugsSparseArray> or C<ParrotOpaqueHash> or so on. So I'd tend to agree that roles "are the heavyweights in the type department."
I've spent a few minutes with no luck trying to draw the actual discussion out of the #perl6 logger, but I'm pretty sure this was the gist.
My (probably lame) interpretation of the Weltanschauung of Perl's typing is that roles, classes, type parameters, and type sets (junctive types, subsets, and mixtures thereof) are all equally relevant to the type system, and are all equally "typish" (though perhaps some are more primitive and some are more sugary).
Unless you're actually composing or inheriting from something, you shouldn't care whether its type derives from a role, a class, a type set, or a type parameter. (And if you are composing or inheriting from it, you're not so much interested in its typishness as its behavior. Your new type will be/do whatever type(s) it inherited/composed, and will also be/do itself; beyond that, you shouldn't care....)
My gut feeling is that in real-world Perl 6 code we'll see a lot of both classes and roles being used as types. Roles will be more common typing particles when interacting with the Perl core or parts of other large code bases, and when you desire type safety. Classes will be more common when you just have a local need to have something to instantiate, or you want SMD or MMD. When programming in the large, the benefits of having a role will often be clearer; when programming in the small, a class will often (C<but> not always ;) be more expeditious.
I think the question (which you didn't directly raise, but I've heard from others) of whether "role" or "class" will have primacy is kind of as pointless as asking whether "subroutines" or "code blocks" have primacy: you can't use the former without the latter; the former is a useful abstraction for the latter, especially when code gets larger or is meant for sharing; and while each have places where they're more appropriate, either can be used in place of the other given a bit of syntactic twiddling.
I know that S12 states "The type system of Perl consists of roles, classes, and subtypes" but I don't have a clear picture of the inner workings or the formal model of this type system. E.g. what actually constitutes a type? How are the classes related to types? There is this fuzzy concept that a class is also a role of the same name as far as typing is concerned. How is the subtyping relation defined?
I can read S12 as saying that classes always do an eponymous role, and so role is what typing is "really" based on. Or alternatively, since when a role is used as if it were a class, it constructs an anonymous class that composes it, that class is what typing is "really" based on. But I don't see that it matters one way or the other; they seem functionally equivalent to me--as would having type based on C<where> subsets, or having all these things participate equally, or any other angle you might want to look at it from. The behavior seems pretty ecumenical to me.
In other words, I agree that it's fuzzy, but I personally read the fuziness as intentional, so as to allow implementations flexibility and prevent bad dependencies on particular "inner workings" of the type system.
Trey
