Description Stephan Herrmann 2010-06-11 10:11:48 EDT

(originally from http://trac.objectteams.org/ot/ticket/174)

When a role is bound to a dependent type (another role), currently two hacks ensure that the behavior is as desired:

 * An observer mechanism is generated into the base roles in order to propagate 
   team activation from one role to its implicit sub role (cannot share static
   role fields) (StaticSliceBaseMethodTransformation)
 * A lift method whose base type is a role first checks if the role's 
   enclosing instance is identical to the anchor given after playedBy 
   (Lifting.maybeCreateTeamMemberCheck()). 

    team class UpperTeam {
       final LowerTeam anchorForLowerRoles = ...;
       class UpperRole playedBy LowerRole<@anchoreForLowerRoles> {}
    }

Both hacks could perhaps be avoided, if the team registration code would be changed from using static fields

    class LowerRole {
      static Team[] _OT$activeTeams; 
      // etc.
    }

to using non-static fields in the enclosing team:

    class LowerTeam {
      Team[] _OT$activeTeamsForContainedRoles;
      // etc.
    }

Now the activation code in UpperTeam would have to be changed from
    LowerRole._OT$addTeam(this);
to
    this.anchorForLowerRoles._OT$addTeamForContainedRoles(this);

Thus dynamic binding following anchorForLowerRoles would transport the 
activation into the exact correct context.

Accordingly, initial wrappers would fetch active teams from their enclosing team.

----
today's addition:
It seems that LowerTeam can indeed hold two kinds of team registrations,
if the team itself is bound as the base class of another role.

However, all base-side dispatch code in a role class would always use the
new fields (no need to merge activations from different lists etc.).


Additionally more levels of nesting need more investigation.