Home » Language IDEs » Objectteams » What makes a class a role?
| What makes a class a role? [message #515841] |
Sun, 21 February 2010 18:43  |
 Eugene Hutorny
Messages: 110
Registered: January 2010 |
Senior Member |
|
|
Hi Stephan,
In OT/J you have bound and unbound roles. The documentation says: "An unbound role will never be attached to a base object", however, according "to the prevailing notion of roles" a role cannot exist without an intrinsic while unbound roles can be solely instantiated. Therefore notion of "unbound roles" can be downscaled to value-bound virtual inner classes. Thereby, statement "A bound role may inherit from an unbound role" can be rephrased as "a role may inherit from a class", which is also does not confirm to the prevailing notion of roles.
Also, the original statement "an unbound role will never be attached to a base object" is not obeyed when taken in a wider sense, please take a look at the following example:
public class AC {}
public team class AT {
public class AR { }
}
public team class BT extends AT {
public class BR extends AR playedBy AC { }
public AR lift(AC as AR ac) {
return ac;
}
public AR anew() {
return new AR();
}
}
public static void main(String[] args) {
final BT bt = new BT();
AR<@bt> ar = bt.anew(); // AR as an object
AR<@bt> br = bt.lift(new AC()); // AR as a role of AC
}
Cheers,
Eugene
[Updated on: Sun, 21 February 2010 18:45] Report message to a moderator |
|
|
| Re: What makes a class a role? [message #516535 is a reply to message #515841] |
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 JAO07.
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 stacking, nesting and layering.
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 #517272 is a reply to message #516535] |
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
|
|
|
| Re: What makes a class a role? [message #518619 is a reply to message #517272] |
Thu, 04 March 2010 16:14 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
| Eugene Hutorny wrote on Fri, 26 February 2010 13:38 | Hi Stephan,
Thank you for your explanations. What I would like to emphasize is that I am not blaming, ...
|
Thanks
I said "blame" because I somehow regret introducing the term "unbound role"
instead of something more neutral ("team participant" or the like).
| Quote: |
I got feeling that such restriction would be beneficial, but have no arguments for that yet.
|
My simplest example against such restriction is in the Stopwatch example.
Look at this role:
protected class WatchDisplay extends JFrame playedBy StopWatch {...
The view is a role of its model (playedBy) and it is a UI element (extends).
Isn't that a useful, natural why to implement this?
| Quote: |
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 {
|
Orthogonality is a bold claim. I tend to see it as a goal - nothing you can
easily achieve 100 percent. Next I wouldn't say classes are orthogonal
to roles, but different uses of classes should be orthogonal to each other.
If a class is used as a role it shouldn't prevent me from also using it as a
- superclass, subclass
- baseclass
- team
In other words, the relationships subclassing, roleplaying, rolecontainment
should approximate orthogonality as closely as possible.
| Quote: |
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 )
|
OK, here we enter the realm of pragmatic intentions. You're right, your
suggested syntax would indeed be more orthogonal than what we have
in OT/J. It would allow you to more explicitly define more distinct combinations.
There's some deliberation in why we did not introduce that syntax (and I
shall carefully try to separate intentions from purely historic reasons).
virtual class: In OT/J this property is coupled to being an inner class
of a team. Thus making it explicit would allow two things:
(1) Non-virtual team member classes
(2) Virtual classes outside a team
For (1) I consider using "final" as sufficient. It is not exactly the same but
very close.
(2) wouldn't work on its own, because a virtual class needs an instance
as the point of reference for dynamic class lookup. In order to supply such
instance you'd additionally need a value parameter like <Team tthis>.
value parameter: Explicitly specifying this for a virtual team member
buys us nothing, because a virtual team member must have this parameter
and thus we can leave it implicit (reduce syntactic burden) without loss
of expressiveness.
For the general case we might open the discussion to multiple value parameters.
(OT/J currently restricts this to only one such parameter, but that's a limitation of
the implementation only). Indeed one language (CaesarJ) has been extended
to support virtual binding of classes wrt multiple value parameters. I.e.:
class C <A1 a, B1 b> { ... }
for different subclasses of A1, B1. In that model resolving a class name C
is a matter of constraint solving. I looked at that model and decided that I don't
like the complexity introduced and OTOH see no compelling reasons why we
should bother to accept that complexity. Instead in OT/J value-dependent
classes outside a team are not virtuals.
After deciding against multiple-virtuals, virtual classes outside a team do
not add more conceptual options, but affect only the organization of classes /
files: do virtual classes have to be defined inside their team? Given we
already have role files (OTJLD 1.2.5) I can't see a situation where even more
independent "outside-virtuals" would be beneficial. (They would be independent
dependent classes, right?)
| Quote: |
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 ).
|
I'm not religious in these matters (I hope!), but I'd see making roles even more
independent as a contradiction to the inherent dependence.
In some situations I'd actually recommend to implement would-be-roles
as regular classes, which gives them all the independence you may like,
and then specialize this independent class by a role.
Summarizing: I consider approximating orthogonality an important goal.
Yet, in some situations I chose to couple several concepts, like: a role
is automatically a virtual class. For that I may have two kinds of reasons:
(1) Perhaps I don't see relevant use cases for those concept combinations
that currently are not possible.
(2) Perhaps I actually want to sneak new concepts onto developers that didn't
bother to think about it - like: you don't have to declare a role as virtual, but
while you implement a sub-team you may all the sudden discover that
overriding a role is a cool capability.
This way I'm pushing developers into a direction that I consider useful.
Both kinds of reasons are subjective. The discussion about "playedBy
enclosing" has revealed a restriction that proved to impede useful designs.
If you see further examples of that kind, please let me know so I can weigh
the costs against the benefits. However, adding more syntax just for
the looks of a program - without adding more capabilities - would be a
weak excuse in my view.
cheers,
Stephan
|
|
|
| Re: What makes a class a role? [message #569494 is a reply to message #517272] |
Thu, 04 March 2010 16:14 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Eugene Hutorny wrote on Fri, 26 February 2010 13:38
> Hi Stephan,
>
> Thank you for your explanations. What I would like to emphasize is that I am not blaming, ...
Thanks :)
I said "blame" because I somehow regret introducing the term "unbound role"
instead of something more neutral ("team participant" or the like).
Quote:
> I got feeling that such restriction would be beneficial, but have no arguments for that yet.
My simplest example against such restriction is in the http://wiki.eclipse.org/OTExample_Stopwatch
Look at this role:
protected class WatchDisplay extends JFrame playedBy StopWatch {...
The view is a role of its model (playedBy) and it is a UI element (extends).
Isn't that a useful, natural why to implement this?
Quote:
> 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 {
Orthogonality is a bold claim. I tend to see it as a goal - nothing you can
easily achieve 100 percent. Next I wouldn't say classes are orthogonal
to roles, but different uses of classes should be orthogonal to each other.
If a class is used as a role it shouldn't prevent me from also using it as a
- superclass, subclass
- baseclass
- team
In other words, the relationships subclassing, roleplaying, rolecontainment
should approximate orthogonality as closely as possible.
Quote:
> 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 :) )
OK, here we enter the realm of pragmatic intentions. You're right, your
suggested syntax would indeed be more orthogonal than what we have
in OT/J. It would allow you to more explicitly define more distinct combinations.
There's some deliberation in why we did not introduce that syntax (and I
shall carefully try to separate intentions from purely historic reasons).
virtual class: In OT/J this property is coupled to being an inner class
of a team. Thus making it explicit would allow two things:
(1) Non-virtual team member classes
(2) Virtual classes outside a team
For (1) I consider using "final" as sufficient. It is not exactly the same but
very close.
(2) wouldn't work on its own, because a virtual class needs an instance
as the point of reference for dynamic class lookup. In order to supply such
instance you'd additionally need a value parameter like <Team tthis>.
value parameter: Explicitly specifying this for a virtual team member
buys us nothing, because a virtual team member must have this parameter
and thus we can leave it implicit (reduce syntactic burden) without loss
of expressiveness.
For the general case we might open the discussion to multiple value parameters.
(OT/J currently restricts this to only one such parameter, but that's a limitation of
the implementation only). Indeed one language (CaesarJ) has been extended
to support virtual binding of classes wrt multiple value parameters. I.e.:
class C <A1 a, B1 b> { ... } could be specialized to all combinations like "C<A2 a, B1 b>", "C<A1 a, B2 b>"
for different subclasses of A1, B1. In that model resolving a class name C
is a matter of constraint solving. I looked at that model and decided that I don't
like the complexity introduced and OTOH see no compelling reasons why we
should bother to accept that complexity. Instead in OT/J value-dependent
classes outside a team are not virtuals.
After deciding against multiple-virtuals, virtual classes outside a team do
not add more conceptual options, but affect only the organization of classes /
files: do virtual classes have to be defined inside their team? Given we
already have role files (OTJLD 1.2.5) I can't see a situation where even more
independent "outside-virtuals" would be beneficial. (They would be independent
dependent classes, right?)
Quote:
> 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 :) ).
I'm not religious in these matters (I hope!), but I'd see making roles even more
independent as a contradiction to the inherent dependence.
In some situations I'd actually recommend to implement would-be-roles
as regular classes, which gives them all the independence you may like,
and then specialize this independent class by a role.
Summarizing: I consider approximating orthogonality an important goal.
Yet, in some situations I chose to couple several concepts, like: a role
is automatically a virtual class. For that I may have two kinds of reasons:
(1) Perhaps I don't see relevant use cases for those concept combinations
that currently are not possible.
(2) Perhaps I actually want to sneak new concepts onto developers that didn't
bother to think about it - like: you don't have to declare a role as virtual, but
while you implement a sub-team you may all the sudden discover that
overriding a role is a cool capability.
This way I'm pushing developers into a direction that I consider useful.
Both kinds of reasons are subjective. The discussion about "playedBy
enclosing" has revealed a restriction that proved to impede useful designs.
If you see further examples of that kind, please let me know so I can weigh
the costs against the benefits. However, adding more syntax just for
the looks of a program - without adding more capabilities - would be a
weak excuse in my view.
cheers,
Stephan
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:02:10 GMT 2024
Powered by FUDForum. Page generated in 0.03375 seconds |
] 
Search
Help
Register
Login
Home
