Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Suggestion on callin bindings
Suggestion on callin bindings [message #505690] Mon, 04 January 2010 09: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 #506164 is a reply to message #505690] Wed, 06 January 2010 07:22 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 999
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 08:21]

Report message to a moderator

Re: Suggestion on callin bindings [message #506601 is a reply to message #506164] Fri, 08 January 2010 04:57 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Wed, 06 January 2010 07:22

This is an interesting proposal indeed.
A bit of history in this context:

...

What do you think? Would that help?
Stephan


I understand your reasoning. IMHO, default option should be the one most frequently used or the one guessed by a user who has read just the first page of the manual Smile

Similarly to mentioned @RegisteredBasesOnly there could be @BindBaseToALLInstances which would instruct the compiler not to generate default guard.
Re: Suggestion on callin bindings [message #567115 is a reply to message #506164] Fri, 08 January 2010 04:57 Go to previous message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Wed, 06 January 2010 07:22
> This is an interesting proposal indeed.
> A bit of history in this context:
>
> ...
>
> What do you think? Would that help?
> Stephan


I understand your reasoning. IMHO, default option should be the one most frequently used or the one guessed by a user who has read just the first page of the manual :)

Similarly to mentioned @RegisteredBasesOnly there could be @BindBaseToALLInstances which would instruct the compiler not to generate default guard.
Previous Topic:compilation problems with a generic callin binding
Next Topic:ClassCastException when instanceof is true
Goto Forum:
  


Current Time: Sat Aug 30 18:34:00 EDT 2014

Powered by FUDForum. Page generated in 0.01732 seconds