Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Some questions on design decisions
Some questions on design decisions [message #568559] Fri, 19 February 2010 10:31 Go to next message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
Hi Stephan,

I have some questions on design decisions that OT/J is based on:

1. Order of after callins
When callin methods from several roles are bound to the same based method, after callins are called in the same order as before callins. Would not it be better to have reverse order for after callins (e.g. LIFO)? The motivation behind this is the following the around callins may be used to allocate and free resources and the LIFO pattern is preferable for this case.

2. Currently the team activation mode (local/global) is determined by the team user. In my opinion, it should be an explicit decision of the team vendor. And the language shall discourage the activation mode misusage.

3. Currently it is not possible for a team to play a role of its own (Illegal base class T, is an enclosing type of R (OTJLD 2.1.2(b))). Not clear why this restriction is introduced since the team may play a role in a descendant team.
Re: Some questions on design decisions [message #568604 is a reply to message #568559] Fri, 19 February 2010 13:04 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Eugene Hutorny wrote on Fri, 19 February 2010 05:31
> 1. Order of after callins
> When callin methods from several roles are bound to the same based method, after callins are called in the same order as before callins. Would not it be better to have reverse order for after callins (e.g. LIFO)? The motivation behind this is the following the around callins may be used to allocate and free resources and the LIFO pattern is preferable for this case.

If you are talking about the semantics of "precedence" than this seem to be
http://trac.objectteams.org/ot/ticket/328, right?
This issue was discovered by a student working on refactorings.

Eugene Hutorny wrote on Fri, 19 February 2010 05:31
> 2. Currently the team activation mode (local/global) is determined by the team user. In my opinion, it should be an explicit decision of the team vendor. And the language shall discourage the activation mode misusage.

My first answer would be a no and a yes.
No, I consider team activation to a large part as a matter of system composition,
not component building. Specifically the ordering of team activation can only
be determined by the system, not the individual team.
Yes, since team activation boils down to creating an instance and
calling activate() the team can indeed implement these things in a way as
to prevent "misusage", like: if no default constructor exists, activation via
configuration file (§5.5) is not possible, if a team overrides activate(Thread)
and checks whether or not the argument is the constant ALL_THREADS it
may simply ignore bogus attempts, throw an exception etc.

By local/global activation do you refer to per-thread vs. all threads or to
explicit using activate or within vs. §5.5? Do you have an example of what
misusage you'd like to prevent?

Eugene Hutorny wrote on Fri, 19 February 2010 05:31
> 3. Currently it is not possible for a team to play a role of its own (Illegal base class T, is an enclosing type of R (OTJLD 2.1.2(b))).

Not sure I understand you. Something like this?
public team class MyTeam {
protected class RoleForTeam playedBy MyTeam {
}
}
Any reasons why not use team fields and methods instead of
fields and methods of RoleForTeam? So, yes the team can certainly
be a participant in the interaction among roles, but it needs no role for
that. And if you really prefer a separate class (for better encapsulation e.g.)
why not use an unbound role, which still has access to all team methods
via MyTeam.this.m() rather than via callout.
A role is usually a view of something outside the team. Maybe I didn't
understand your intention.

Quote:
> Not clear why this restriction is introduced since the team may play a role in a descendant team.

If I understand correctly the compiler allows a situation that it should no
by intention. Again, do you have an example?

Stephan
Re: Some questions on design decisions [message #568619 is a reply to message #568604] Fri, 19 February 2010 14:19 Go to previous message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Fri, 19 February 2010 08:04
> If you are talking about the semantics of "precedence" than this seem to be
> trac ticket 328, right?
> This issue was discovered by a student working on refactorings.


Yes, that's what I meant.

Stephan Herrmann wrote on Fri, 19 February 2010 08:04
> Eugene Hutorny wrote on Fri, 19 February 2010 05:31
> > 2. Currently the team activation mode (local/global) is determined by the team user. In my opinion, it should be an explicit decision of the team vendor. And the language shall discourage the activation mode misusage.
>
> My first answer would be a no and a yes.
> No, I consider team activation to a large part as a matter of system composition,
> not component building. Specifically the ordering of team activation can only
> be determined by the system, not the individual team.
> Yes, since team activation boils down to creating an instance and
> calling activate() the team can indeed implement these things in a way as
> to prevent "misusage", like: if no default constructor exists, activation via
> configuration file (§5.5) is not possible, if a team overrides activate(Thread)
> and checks whether or not the argument is the constant ALL_THREADS it
> may simply ignore bogus attempts, throw an exception etc.


Yes, a team may block bogus attempts, but this will be runtime exception, not a compilation error.

Stephan Herrmann wrote on Fri, 19 February 2010 08:04
> By local/global activation do you refer to per-thread vs. all threads or to
> explicit using activate or within vs. §5.5? Do you have an example of what
> misusage you'd like to prevent?


Yes, I meant per-thread vs. all threads activation.

For example there are two threads, first thread activates a team per thread, another - activates for all threads.
When the first thread deactivates the team (per thread) - would it be active for this thread?


// 1st thread 2nd thread
ateam.activate();
ateam.activate(ALL_THREADS)
ateam.deactivate();
// is ateam active for this thread?


Stephan Herrmann wrote on Fri, 19 February 2010 08:04
> Eugene Hutorny wrote on Fri, 19 February 2010 05:31
> > 3. Currently it is not possible for a team to play a role of its own (Illegal base class T, is an enclosing type of R (OTJLD 2.1.2(b))).
>
> Not sure I understand you. Something like this?
> public team class MyTeam {
> protected class RoleForTeam playedBy MyTeam {
> }
> }
> Any reasons why not use team fields and methods instead of
> fields and methods of RoleForTeam? So, yes the team can certainly
> be a participant in the interaction among roles, but it needs no role for
> that. And if you really prefer a separate class (for better encapsulation e.g.)
> why not use an unbound role, which still has access to all team methods
> via MyTeam.this.m() rather than via callout.
> A role is usually a view of something outside the team. Maybe I didn't
> understand your intention.
>
> Quote:
> > Not clear why this restriction is introduced since the team may play a role in a descendant team.
>
> If I understand correctly the compiler allows a situation that it should no
> by intention. Again, do you have an example?
> Stephan


Please take a look at the example below:

// this class is needed just to overcome compiler error
public abstract team class Server {
public abstract String respond();
}

public team class WebServer extends Server {

public String respond() {
return "HTTP 1.1";
}
protected class Maintenance playedBy Server {
String respond() <- replace String respond();
@SuppressWarnings("basecall")
callin String respond() {
return "Server is on maintenace";
}
}
public void beginMaintenance() {
activate(ALL_THREADS);
}
public void endMaintenance() {
deactivate(ALL_THREADS);
}

server.respond(); // returns "HTTP 1.1"
server.beginMaintenance();
server.respond(); // returns "Server is on maintenace"
server.endMaintenance();


If such constructions are not allowed by language design, compiler should not allow a role played by a team superclass as well, e.g. issue error on Maintenance playedBy Server.
If such construction is allowed, compiler should not complain about Maintenance playedBy WebServer.
Previous Topic:IDE for a language embedded in Java
Next Topic:What are the origins of value bound classes?
Goto Forum:
  


Current Time: Fri Mar 29 09:09:59 GMT 2024

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

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

Back to the top