Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Suggestion on callin bindings
Suggestion on callin bindings [message #567001] Mon, 04 January 2010 14:23 Go to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Hello,

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?
Re: Suggestion on callin bindings [message #567056 is a reply to message #567001] Wed, 06 January 2010 12:22 Go to previous message
Stephan Herrmann is currently online Stephan Herrmann
Messages: 1023
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
Previous Topic:compilation problems with a generic callin binding
Next Topic:ArrayIndexOutOfBoundsException with multithreaded use of a callin
Goto Forum:
  


Current Time: Thu Oct 23 20:08:41 GMT 2014

Powered by FUDForum. Page generated in 0.01489 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software