Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » A question on design motivation for callout syntax
A question on design motivation for callout syntax [message #568206] Fri, 12 February 2010 20:43 Go to next message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
Hi Stephan,

May you please shed some light on the motivations for designing syntax for callin and callout bindings in the OT/J way?
I'm a little bit concerned because this syntax creates a new space for the executable code. In Java there were two spaces (correct me if I am wrong): (1) blocks '{}' - method and constructor bodies, and static blocks; and (2) initializers - expressions after '='.
In OT/J there is a new space before '->' and after '<-' in parameter mappings.
An expression may end up with an exception, and, thus may require try catch block which does not seem to fit the parameter mappings.
The same semantic could be achieved without introducing this new syntax:

OT/J syntax:

Integer absoluteValue(Integer integer) -> int abs(int i) with {
integer.intValue() -> i,
result <- new Integer(result)
}

float earnEuro() -> float earnDM () with {
result <- result / 1.95583f
}


Plain Java syntax:

Integer absoluteValue(Integer integer) {
return new Integer(base.abs(integer.intValue()));
}

float earnEuro() {
return base.earnDM () / 1.95583f ;
}


The latter does not seem to have much boilerplate code, does it?
Re: A question on design motivation for callout syntax [message #568244 is a reply to message #568206] Fri, 12 February 2010 22:22 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Hi Eugene,

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 :)

cheers,
Stephan

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 Go to previous message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
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

Regards,

Eugene
Previous Topic:Problems with Brole playedBy Arole
Next Topic:OTDT 1.4.0M3 released
Goto Forum:
  


Current Time: Fri Mar 29 12:03:04 GMT 2024

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

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

Back to the top