|Re: A question on design motivation for callout syntax [message #568244 is a reply to message #568206]
||Fri, 12 February 2010 22:22
| Stephan Herrmann
Registered: July 2009
thanks for this question, I understand your doubts so let me try
to convince you.
When initially designing the syntax an important guideline was
symmetry, so I wanted callout and callin bindings to look alike
as much as possible except for reverting arrow directions.
The plain-Java syntax you suggest for callout is, however, not
possible for callin.
This gives the initial reason, why we have any special syntax
for callout. At this point we could discuss the matter of parameter
mappings vs. additional wrapper methods but that's perhaps not
the main point here.
Later in the design of the language it turned out that the special
syntax indeed helps for quite a different purpose: to make all
connections between a role and its base explicit and thus help
for better encapsulation. In the current language design
this motivation might be considered even stronger than the initial
thoughts on symmetry.
Actually, your observation regarding a new space hits the nail,
maybe in a slightly different way than you were thinking:
When looking at a role-base pair, we have three "spaces", or scopes:
The base class is implemented only in its own terms, it cannot
mention the role
The role class is essentially implemented only in terms of what's
contained in its team, it should not mention its base
Only explicit bindings (playedBy,callout,callin) connect the two
scopes and are allowed to mention names from both sides
The above regime is enforced once you tell the compiler that
"Violations of binding conventions" are Errors. Then you
have to import your base classes using "import base ...".
This import does not entitle you to mention the base class
anywhere except in bindings.
Now even parameter mappings come to new life: consider the
bindings as the only gateway between a role and its base.
Parameter mappings are considered as "within the gate",
i.e., they are no man's land.
That's why it is possible, to use callout bindings with parameter
mappings for virtual refactorings (see https://trac.objectteams.org/ot/wiki/OtPatterns/VirtualRefac toring).
Last but certainly not least, callout bindings are used for
controlling decapsulation: in the syntax you suggest, it would
be necessary to investigate all code in all role methods in
order to find which base methods/fields are decapsulated.
With explicit callout bindings abstraction is raised one level:
instead of allowing individual statements to decapsulate at
their own deliberation, you are forced to add callout bindings
to the role class should you want to use decapsulation.
In one of our papers we call this "restricting the loop-hole":
given that a role as special privileges towards its base
we want to provide the best control to still keep coupling
between role and base at a minimum. Explicit interfaces
are the standard concept for low coupling. Callout bindings
are explicit interfaces for decapsulation.
I hope this gives a comprehensible account of why OT/J
has special syntax for callout bindings. It may or may not
convince you, but let's see :)
PS: I didn't address the issue of exceptions. If you like
I could expand on that, too, which would then also include
considerations regarding guard predicates, btw.
|Re: A question on design motivation for callout syntax [message #568289 is a reply to message #568244]
||Mon, 15 February 2010 09:28
| Eugene Hutorny
Registered: January 2010
Stephan Herrmann wrote on Fri, 12 February 2010 17:22|
> Hi Eugene,
> thanks for this question, I understand your doubts so let me try
> to convince you.
> I hope this gives a comprehensible account of why OT/J
> has special syntax for callout bindings. It may or may not
> convince you, but let's see :)
This is quite solid reasoning, you almost convinced me :).
The only argument I can contrast - the subclass-to-role refactoring case.
This may be the key use case when applying OT/J to a live product and also may occur in projects that were started with OT/J due to scope expansion.
Thus refactoring subclasses to roles should create as few obstacles as possible.
Stephan Herrmann wrote on Fri, 12 February 2010 17:22
> PS: I didn't address the issue of exceptions. If you like
> I could expand on that, too, which would then also include
> considerations regarding guard predicates, btw.
Yes, please expand on this
Powered by FUDForum
. Page generated in 0.01439 seconds