Home » Language IDEs » Objectteams » Essence of the OT/J language
| | |
| Re: Essence of the OT/J language [message #729998 is a reply to message #729453] |
Tue, 27 September 2011 12:49   |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Aivar Annamaa wrote on Mon, 26 September 2011 10:43Thanks! The blog post didn't exactly answer my question, but motivated to dig some more 
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!
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 #731597 is a reply to message #730394] |
Sat, 01 October 2011 23:11 |
Stephan Herrmann
Messages: 1853
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
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.
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 
Stephan
|
|
| |
| Re: Essence of the OT/J language [message #732106 is a reply to message #731904] |
Mon, 03 October 2011 22:50 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Aivar Annamaa wrote on Mon, 03 October 2011 14:51At 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
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"
Maybe, what you are looking for is actually a Method that tells you which tool to apply when? So, teaching is important!
cheers,
Stephan
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 12:42:16 GMT 2024
Powered by FUDForum. Page generated in 0.02342 seconds |
] 
Search
Help
Register
Login
Home
