On Wednesday 25 October 2006 03:04, Trey Harris wrote: > 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."
Yes. When you specify a type to constrain some operation, you specify that the target entity must perform that role. > 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. Yes. > 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. Well... maybe. I believe strongly that you can build a really good system with roles as the fundamental abstraction and where classes are a specialization, but doing the other way around is much more difficult and less cohesive. > I can read S12 as saying that classes always do an eponymous role, and so > role is what typing is "really" based on. Yes. > 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. That fuzziness is classic $Larry. Some of the rest of @Larry can be more *mumble*matic. -- c
