Home » Language IDEs » Objectteams » What makes a class a role?
|
| Re: What makes a class a role? [message #569036 is a reply to message #568759] |
Wed, 24 February 2010 11:22   |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Hi Eugene,
For a due response I should separate two issues: what's the best terminology
for talking about roles etc. and what's the semantics of the language.
Certainly there is a connection between the 'meaning' implied by the terms
and the 'semantics' defined in the language definition, but let's for the
purpose of this post use 'meaning' for the intuitive understanding by a
developer and 'semantics' for the precise rules used by the compiler.
Starting with the semantics, it seems you would like to prohibit roles
R1 and R2 in this example:
public class Regular { }
public team class MyTeam {
protected class Member { }
protected class R1 extends Member playedBy SomeBase { }
protected class R2 extends Regular playedBy OtherBase { }
}
Your saying "'a role may inherit from a class', which is also does not conform
to the prevailing notion of roles" would let me conclude that both extends
clauses are illegal, because Member and Regular are not "roles" in your terms.
I'm not sure what to conclude for this example:
public team class MySuperTeam {
protected class Member { }
}
public team class MySubTeam extends MySuperTeam {
@Override
protected class Member playedBy SomeBase { }
}
The "role" in MySubTeam implicitly inherits from a "class", is that OK?
In practice all three inheritance relations are powerful ways of expressing
a separation into an abstract concept and a concrete implementation,
of re-using existing classes etc. In fact the last example is the beginning of
our oldest pattern: "Connector" as propagated by our FlightBonus example
and many more.
Conceptually the language is much more orthogonal if it doesn't restrict
what kinds of classes a role can inherit from. Luckily this conceptual view
agrees with the pragmatist view that welcomes all combinations resulting
from such orthogonality, and I'm convinced that it's a strength of OT/J
that it does allow all of the above combinations and more.
How can we connect this to the prevailing terminology? Here I must admit
that in the early stages of the Object Teams project I wasn't precisely aware
of this aspect of the 'prevailing notion of roles'. I failed to see, that commonly
classes like Member above would not be considered as "roles".
As a result my terminology accidentally deviates from the 'prevailing notion'.
I've been blamed for this before.
For an unambiguous terminology I've proposed a meta model for Object Teams
- written in Object Teams, which can be found in Fig. 10 of http://www.objectteams.org/publications/JAO07.pdf
Also this meta model contains the bug you complain about. Actually the middle
part of the picture should say a "Collaboration" is represented by a "Team"
which contains any number of "Participants".
In the context of a "Collaboration" a "Class" can play the role "Participant."
A true "Role" is only relevant in the context of "RolePlaying". And the most
precise answer to your statement would be: A "Role" in the context of
"RolePlaying" requires that you have a "Participant" in a "Collaboration"
which in turn requires that you have a "Class". In other words: "Participant"
and "Role" are just different ways of looking at a "Class" (from the perspective
of a given context like "Collaboration" or "RolePlaying"). I hope the circularity
doesn't confuse you too badly :)
One message of this meta model is: all these things "Teams", "Bases",
"Participants", "Roles" are intrinsically "Classes" (leaving out the instance
level for this discussion). From this interpretation I constructed the orthogonality
mentioned above: Even if something is a "Role", it is still based on a "Class"
and thus all you can do with a "Class" you can also do with a "Role"
(only the fine-print mentions a few unavoidable restrictions).
The other message is: whether you consider something as a "Role" or
a "Base" etc. depends solely on your context/perspective. And having
Classes that play several of these meta roles is the foundation for the structures
of http://www.objectteams.org/def/1.3/s2.html#s2.7
Luckily, nothing of this discussion affects the syntax of OT/J: since we don't
use a "role" keyword the language OT/J is actually neutral towards the
terminology. Would I write the OTJLD from scratch today, I'd try to avoid
the "unbound role" thing in favor of "participant", but at the current point
of the project I'm afraid a rewrite might actually cause more confusion.
While writing this response, I strongly feel I should add a paragraph to the
OTJLD relating the terminology of that document to a perceived prevailing
notion outside the document. That paragraph should help mapping the
OTJLD to other literature on roles.
Yes, terminology is difficult, because it depends on what you want to
express, but it's a strength of the role concept to make context dependence
explicit :)
Stephan
|
|
|
| Re: What makes a class a role? [message #569272 is a reply to message #569036] |
Fri, 26 February 2010 18:38 |
Eugene Hutorny
Messages: 110
Registered: January 2010 |
Senior Member |
|
|
Hi Stephan,
Thank you for your explanations. What I would like to emphasize is that I am not blaming, not criticizing, and not arguing for immediate changes in the language, but rather trying to sow the seeds on the soil of OT/J and hoping that some of them may take the roots and perhaps grow as trees :)
Stephan Herrmann wrote on Wed, 24 February 2010 06:22
> Starting with the semantics, it seems you would like to prohibit roles R1 and R2 in this example:
> public class Regular { }
> public team class MyTeam {
> protected class Member { }
> protected class R1 extends Member playedBy SomeBase { }
> protected class R2 extends Regular playedBy OtherBase { }
> }
I got feeling that such restriction would be beneficial, but have no arguments for that yet.
Stephan Herrmann wrote on Wed, 24 February 2010 06:22
> In practice all three inheritance relations are powerful ways of expressing
> a separation into an abstract concept and a concrete implementation,
> of re-using existing classes etc. In fact the last example is the beginning of
> our oldest pattern: "Connector" as propagated by our FlightBonus example
> and many more.
>
> Conceptually the language is much more orthogonal if it doesn't restrict
> what kinds of classes a role can inherit from. Luckily this conceptual view
> agrees with the pragmatist view that welcomes all combinations resulting
> from such orthogonality, and I'm convinced that it's a strength of OT/J
> that it does allow all of the above combinations and more.
In my understanding "classes are orthogonal to roles" means "classes and roles have one point of intersection", while in OT/J a role may intersect with a class in two points:
public team MyTeam {
public class MyRole extends MyClass playedBy MyClass {
Stephan Herrmann wrote on Wed, 24 February 2010 06:22
> Luckily, nothing of this discussion affects the syntax of OT/J: since we don't
> use a "role" keyword the language OT/J is actually neutral towards the
> terminology. Would I write the OTJLD from scratch today, I'd try to avoid
> the "unbound role" thing in favor of "participant", but at the current point
> of the project I'm afraid a rewrite might actually cause more confusion.
Roles definitely are "thicker" than classes but on the language level they appear as (almost) plain classes, which, in my opinion, devaluates the OT/J-unique features. If programmers would have to type
public virtual class role MyRole<Team> playedBy MyClass {
they would value each individual feature, (or, at least, would be motivated to learn what those new words stand for :) )
Also, this kind of syntax would allow defining not-virtual-not-value-bound-inner-classes in teams and open possibilities for defining roles outside of the teams (I suppose the latter may sound as heresy :) ).
Cheers,
Eugene
|
|
|
Goto Forum:
Current Time: Wed Apr 24 22:25:49 GMT 2024
Powered by FUDForum. Page generated in 0.02704 seconds |
] 
Search
Help
Register
Login
Home
