Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Essence of the OT/J language
Essence of the OT/J language [message #726584] Sun, 18 September 2011 20:19 Go to next message
Aivar Annamaa is currently offline Aivar Annamaa
Messages: 32
Registered: July 2009
Member
Hi!

I'm interested in OO languages and therefore I'm trying to understand the essence of OT/J. I tried to read http://wiki.eclipse.org/OTJ_Primer and "A Precise Model for Contextual Roles", but it's hard to understand these text as I fail to see whether concepts of "team" and "role" are just some kind of syntactical convenience, a way to add runtime flexibility, a way to add methodological flexibility/agility or something else. I guess the main problem is that I haven't found explanation about how these concepts map to traditional OO concepts.

Could anyone provide an example program in plain Java with a corresponding example in OT/J which demonstrates the benefits of OT/J?

best regards,
Aivar
Re: Essence of the OT/J language [message #727159 is a reply to message #726584] Tue, 20 September 2011 14:43 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Hi Aivar,

thanks for your interest.

I've taken the opportunity to blog about what might be seen as the essence of OT/J.

If that blog post doesn't answer your question or if you have specific questions regarding the documentation you read, please keep asking.

best,
Stephan
Re: Essence of the OT/J language [message #729453 is a reply to message #727159] Mon, 26 September 2011 08:43 Go to previous messageGo to next message
Aivar Annamaa is currently offline Aivar Annamaa
Messages: 32
Registered: July 2009
Member
Thanks! The blog post didn't exactly answer my question, but motivated to dig some more Smile

The most helpful piece of text I found was on http://wiki.eclipse.org/OTJ_Primer/Role_Playing saying "The above implies that the playedBy relation is very similar to inheritance:" -- I guess this was what I was looking for. But this section brings the question of how is role playing then different from delegation? Is the difference in callin methods and Activation?

About activation: does it mean that the behaviour of the base object (and all the role objects attached to it) can be changed by a "switch" which can be located anywhere in the code? Doesn't this hide dependencies and make code more fragile?

best regards,
Aivar
Re: Essence of the OT/J language [message #729998 is a reply to message #729453] Tue, 27 September 2011 12:49 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Aivar Annamaa wrote on Mon, 26 September 2011 10:43
Thanks! The blog post didn't exactly answer my question, but motivated to dig some more Smile

The most helpful piece of text I found was on http://wiki.eclipse.org/OTJ_Primer/Role_Playing saying "The above implies that the playedBy relation is very similar to inheritance:" -- I guess this was what I was looking for. But this section brings the question of how is role playing then different from delegation? Is the difference in callin methods and Activation?


If you compare to what you can do in plain Java: yes, there you can only do the equivalent of callout (forwarding) but not callin (interception), and thus in Java you have a crippled form of delegation where the specialization cannot really override inherited behavior.
Try using the template&hook pattern: with standard inheritance between classes it works, also with "true delegation" it works, but with Java-style delegation it's broken: as soon as the control flow enters the base (aka. parent or delegatee) you forget where you came from.
(I'm using "true delegation" in the sense of, e.g., the Self programming language).
In the OT/J Primer under "True Delegation" you find the self call that should be bound to Employee.getOfficePhoneNo(). You can't directly do this in Java, but you can using "true delegation" and that's what role playing with callout and callin also supports.


So role playing can do everything that "true delegation" can also do, and it can do more: consistent dynamic (de)activation ... on we go ...

Quote:

About activation: does it mean that the behaviour of the base object (and all the role objects attached to it) can be changed by a "switch" which can be located anywhere in the code? Doesn't this hide dependencies and make code more fragile?

The switch is located in the enclosing team (of those roles that define the callins). It can indeed be invoked from any part of the program that has access to the team instance. So if you want to protect the switch, protect the team instance. E.g., if a team should always be active, declare this outside of the program (in the IDE using a launch configuration, in OT/Equinox in plugin.xml etc.): the program has no references to these globally activated team instances and thus cannot mess with them.

Secondly, the IDE visualizes all those dependencies that are introduced by roles, so I wouldn't say they're hidden.

Experience indeed shows that the opposite of what you fear is true: programs are actually easier to maintain and evolve using Object Teams. The cool thing is that this one switch replaces what would normally be dozens of ifs scattered all over your program, and whenever you need to change any of these it's easy to miss some locations which you should change, too. With team activation it's all localized in one place and much easier to keep consistent. Try it, it helps! Smile

BTW, I said "consistent dynamic (de)activation" (above) because having the switch at the team it is guaranteed that activation consistently affects all contained roles of the team.

Is this getting closer to the answers you were seeking?
Stephan
Re: Essence of the OT/J language [message #730394 is a reply to message #729998] Wed, 28 September 2011 09:56 Go to previous messageGo to next message
Aivar Annamaa is currently offline Aivar Annamaa
Messages: 32
Registered: July 2009
Member
Thanks for such a thorough answer!

Yes, the picture is getting clearer now, I guess I need to try a bigger example in order to get the feeling.

I'm not convinced, though, that the kind of delegation that you described is the "true" one Smile I thought that (some) people favour composition (or delegation) over inheritance just because inheritance usually creates bidirectional dependence (methods implemented in superclass can call methods implemented in subclass and vice versa), but with delegation you have clearly unidirectional dependence. (Maybe "dependence" is not the right word here).

And thanks for the Self reference -- now I have another reason to finally get acquainted with it.

best regards,
Aivar

Re: Essence of the OT/J language [message #731597 is a reply to message #730394] Sat, 01 October 2011 23:11 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Aivar Annamaa wrote on Wed, 28 September 2011 11:56

I'm not convinced, though, that the kind of delegation that you described is the "true" one Smile


I'm quoting the term "true delegation" from publications from the programming language research community (like, e.g., by G√ľnter Kniesel) which root back at least to 1986 (e.g., Lieberman).

I know that e.g., in the design pattern community the term is usually used differently. Terminology in the software business certainly doesn't capture the truth. Smile

Quote:

I thought that (some) people favour composition (or delegation) over inheritance just because inheritance usually creates bidirectional dependence (methods implemented in superclass can call methods implemented in subclass and vice versa), but with delegation you have clearly unidirectional dependence. (Maybe "dependence" is not the right word here).


Yes, it's that bidirectional dependency that allows you to apply the template&hook pattern. As any sharp tool it can cut both ways. If you want to avoid this, chances are that your solution will be bloated by workarounds, infrastructure, patterns.

These are no definite statements, but you should always be aware that simple rules for avoiding one specific form of complexity (like: "delegation over inheritance") may come back at you and produce a completely different kind of accidental complexity (like the software bloat you can observe with some design patterns). Object Teams strives for reducing the total complexity, not just one form of it.

Unfortunately, without significantly large examples this discussion involves a lot of hand waving and little verifiable facts Rolling Eyes

Stephan
Re: Essence of the OT/J language [message #731904 is a reply to message #731597] Mon, 03 October 2011 12:51 Go to previous messageGo to next message
Aivar Annamaa is currently offline Aivar Annamaa
Messages: 32
Registered: July 2009
Member
Thanks, you got me thinking whether I've accepted some truths without enough consideration Smile

At the moment I'm still believing that expressing powerful but dangerous things (eg. bidirectional dependency or shared/aliased mutable state) should take more effort than expressing simple and safe (let's say "functional") things. In other words, syntax shouldn't hide the "sharpness".

What's bugging me is that often these technically complex solutions (eg. inheritance and global variables) are conceptually quite simple, at least initially, when the dependency graph is small. (I'm teaching introductory programming class and students understand global variables better than function parameters even though I haven't told them about global variables).

So, I suspect there might be something good between "sharp but dangerous" and "basic but predictable/composable". Surely localization/encapsulation of the sharpness helps (modules, teams). Maybe those initially simple approaches can be made more scalable with some extra ingredient. Certainly worth pondering.
Re: Essence of the OT/J language [message #732106 is a reply to message #731904] Mon, 03 October 2011 22:50 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Aivar Annamaa wrote on Mon, 03 October 2011 14:51
At the moment I'm still believing that expressing powerful but dangerous things (eg. bidirectional dependency or shared/aliased mutable state) should take more effort than expressing simple and safe (let's say "functional") things. In other words, syntax shouldn't hide the "sharpness".


Those are valid points, sure. Some examples from OT/J:

The tool creates roles as protected by default, if you just add "extends Confined" they're actually owned (in terms of alias control) by the enclosing team.

Conversely, passing roles to third party code (which is potentially dangerous, weakens the encapsulation) requires the burden of explicitly spelling out their dependent types.

OTOH, I wouldn't introduce artificial syntactic burdens Smile

Another thing we do is visualize the effect: decorating base classes in the editor with markers linking to roles, callin bindings and decapsulating callout bindings. This way the bidirectionality no longer remains implicit.

Quote:
So, I suspect there might be something good between "sharp but dangerous" and "basic but predictable/composable". Surely localization/encapsulation of the sharpness helps (modules, teams). Maybe those initially simple approaches can be made more scalable with some extra ingredient. Certainly worth pondering.


I think OT/J actually is a big step forward in terms of scalability. Let me know if you've found an "extra ingredient" Smile

Maybe, what you are looking for is actually a Method that tells you which tool to apply when? So, teaching is important!

cheers,
Stephan
Re: Essence of the OT/J language [message #992232 is a reply to message #726584] Fri, 21 December 2012 06:57 Go to previous messageGo to next message
zeeshan zeeshan is currently offline zeeshan zeeshan
Messages: 1
Registered: December 2012
Junior Member
I am very appreciate your site,and your article is useful, thank for sharing us this information.-DEMI
Re: Essence of the OT/J language [message #1005380 is a reply to message #992232] Fri, 25 January 2013 08:12 Go to previous message
Eclipse User
Thanks for sharing information. Actually I had also the same question in mind for a long
time anyways you started this thread & I am so hapy Shocked
Previous Topic:Are there any Software Product Line examples using Object Teams?
Next Topic:Book chapter published: Confined Roles and Decapsulation in Object Teams -- Contradiction or Synergy
Goto Forum:
  


Current Time: Wed Oct 01 20:26:12 GMT 2014

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

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