|
| Re: Suggestion on callin bindings [message #567056 is a reply to message #567001] |
Wed, 06 January 2010 12:22  |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
> 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
|
|
|
Powered by
FUDForum. Page generated in 0.02203 seconds
] 
Search
Help
Register
Login
Home
