Discussion with Stephen Nelson, 2008/10/22

Roles could be understood as a kind of "dynamic subclass." An
association links between the original entity and a role class. The
role class is specific to the original class (e.g., Student is a role
for class Person; Employee is a role for class BusinessPartner).

Roles conform to their original class. A Person instance viewn in role
Employee conforms to class Person.

Roles can add features (operations, associations, ...) beyond what the
original class offers.

If an object enters an association to a role, it can dynamically be
"cast" into an instance of that role resulting in an object that
statically is of the role type, keeping the original object's
identity. Somehow this resembles traversing the association from
original to role, only that the result still has the same identity but
has the extended features and exhibits the extended state as defined
by the role.

As a variant, roles may redefine features of the original class. Now
this becomes tricky from a polymorphism point of view. The role's
features are only available if the *static* type of an object is that
of the role. Therefore, redefinitions that occur by a role don't work
polymorphically. But does it have to be like that? Couldn't the
semantics be that the object with its ID is annotated with the dynamic
type it's supposed to have? This could then be set to either role that
is reachable by navigating the connected graph of role
associations. The "cast" would replace the dynamic type of the object
by that of another role. This would be preserved as the object gets
passed around. The runtime would assert that type replacement can only
happen within a connected graph of roles.

For feature dispatching, the dynamic type is relevant. For association
lookup, only the identity counts. Therefore, as long as the static
type matches during insertion into the association, the object can be
inserted. For example, a Student role object can be inserted into an
association between class Person and something else as a Person.

The runtime identity of an object would then consist of the object ID
plus a type identifier which has to be the original class or any of
the roles in the connected graph of roles attached to the original
type. A reference to an object always has both, the ID and the dynamic
type. Therefore, the dynamic type gets passed along with the object
and gets stored in associations. Therefore, when a Student gets
entered into a Person association, it will be retrieved as a Student
again. Its behavior will be determined by what the Student role class
tells, in particular including any redefinitions of Person features.