On Fri, Oct 14, 2005 at 09:08:45 -0400, Rob Kinyon wrote: > couldn't fix it in my head why there were two separate concepts.
The difference between a class and a role is in the eyes of their consumer - the way in which a class gets new behavior (inheritence, mixin, or role composition style) is fundamentally the thing that determines whether the consumed thing is a class or a role. Ofcourse, to encourage correct use of a consumable unit of behavior, one can use class or role. However, there is more to it, conceptually - roles make much more sense when parametrized over other types, while classes make more sense unparametrized, due to the way they are used. Last I heard there only roles were allowed to be parametrized, but there really isn't any technical difference between classes and roles in this respect either. Frankly I think that classes make just as much sense when parametrized, but i don't really mind parametrizing roles that are really classes to make anonymous classes. This way it is clear that there can never be uninstantiatable classes around. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me kicks %s on the nose: neeyah!!!!!!!!!!!!!!!!!
pgpSXywhAFpZI.pgp
Description: PGP signature
