|
Re: Suggestion on callin bindings [message #506164 is a reply to message #505690] |
Wed, 06 January 2010 12:22 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
Quote: |
By default a callin is bound to all instances of a class, regardless of
whether a particular instance was lifted/bound for this team instance or
not. To restrict callin binding to the bound instances only, a guard
should be applied:
base when(hasRole(base, MyRole.class))
This is a kinda dissonance with the Team Spirit.
Would it be more consistent to have that guard by default and provide an
ability to not apply it when needed?
|
This is an interesting proposal indeed.
A bit of history in this context:
Early versions of OT/J did not support guard predicates. In our paper
on MVC (AOSD 2003) we introduced so-called activation levels. One of
these levels was "FROZEN", which had the following semantics:
"At this level callin bindings are effective for all those
base objects that already have a role object due to a prior
lifting. Base objects that have not yet been lifted are
not effected by callin bindings. [...]"
In early 2005 this mechanism was revised for two reasons:
- The set of activation levels seemed quite arbitrary.
It felt wrong to fix this in the language definition.
- Guard predicates were introduced as a far more general
mechanism for filtering the effect of callin bindings.
With guard predicates it is possible to define arbitrary policies,
including the "FROZEN" activation level (the guard you mentioned).
Yet the question remains what should be the default?
Considering the options for combining multiple guards
(team/role/callin/method guards plus inherited guards)
it became clear that intuition calls for combining predicates with AND.
This means, if we would introduce the mentioned guard as a default
for all roles, we would have no means for removing this guard
since guards can only be strengthened.
I could still think of ways to make it easier to write teams
with true "Team Spirit". First the guard could be pushed out to
the team in order to apply one guard for all roles of the team.
public team class MyTeam base when (hasRole(base)) { ... }
This guard doesn't know the expected role type, which could mean
a slight performance penalty but the semantics are as desired.
Things could still be simplified by introducing an annotation, like:
@RegisteredBasesOnly
public team class MyTeam { ... }
(The annotation name is just for illustration at this point).
The compiler could actually translate this annotation into appropriate
guard predicates for all contained roles.
What do you think? Would that help?
Stephan
[Updated on: Wed, 06 January 2010 13:21] Report message to a moderator
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04326 seconds