In the discussions I've had with Steve, one thing that always
nagged me - what's the difference between a "class" and a "role"? I
couldn't fix it in my head why there were two separate concepts.
Steve, yesterday, mentioned to me that in the metamodel that he's got
so far, Class does Role. This means that you can have Class A does
Class B, and it will DWIM. Additionally, Larry has said that he wants
to be able to instantiate a role.

    This makes gut-sense to me. A role is really just a "class
snippet", complete or not. You can compose these snippets together to
make a larger class. Or, in many cases, you can just instantiate the
"snippet" and have a viable instance. You can also have an incomplete
snippet, just as you can have an incomplete class. This could be
useful for things like interfaces.

    Now, you can have your class inherit from another class, compose
itself from other classes, or both! It's completely up to you. You can
have your roles in an inheritance hierarchy, and it will all just

    What this means is that classes and roles both quack, swim, and
lay eggs. They're both just ducks. Given that, there's no need for two
separate concepts in the implementation. It just makes for a more
complex implementation.

    I need to stress that I'm not suggesting that the keyword "role"
be removed. It won't be the first time we have keywords that mean the
same thing, just with a little sugar added. It definitely improves
maintainability to have separate keywords for separate ideas, even if
they're implemented identically.


Reply via email to