In a message dated Sat, 28 Oct 2006, chromatic writes:
When you specify a type to constrain some operation, you specify that the target entity must perform that role.


That statement is very concise and direct. If the fuzziness I observed about the identity of the basic building block of type was unintentional, this statement should be added to S06.

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.

But I wasn't suggesting that, any more than I was suggesting that code blocks based on anonymous subroutines would be as cohesive as subroutines based on code blocks. I was just saying that both roles and classes could be equally first-class participants in the type system by my reading of S06 and S12: I don't see any necessity, short a statement like yours I quoted above, for classes to be coerced into a role before they can act as a type.

Trey

Reply via email to