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 #514212] Fri, 12 February 2010 15:43 Go to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
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 #514230 is a reply to message #514212] Fri, 12 February 2010 17:22 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 997
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 VirtualRefactoring).

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 Smile

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 #514417 is a reply to message #514230] Mon, 15 February 2010 04:28 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
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 Smile



This is quite solid reasoning, you almost convinced me Smile.
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
Re: A question on design motivation for callout syntax [message #514777 is a reply to message #514417] Tue, 16 February 2010 10:46 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 997
Registered: July 2009
Senior Member
Quote:
The only argument I can contrast - the subclass-to-role refactoring case.

Well, refactoring - just as everything related to evolution - is at the core of
our undertaking. A recent student's thesis on this topic is available in German
only, sorry. I'm thinking of where and how to give a complete account
of this topic. I think I will schedule this as an Eclipse article.


Quote:
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.
Quote:
Yes, please expand on this



Actually, I see two related issues: exceptions and side effects.
OT/J introduces two places where the syntax calls for an expression,
not a block of statements: parameter mappings and guard predicates,
so I'd like to discuss both places together.

Ideally, Java would support a method modifier - say - "pure" to mark
a method that neither causes a side effect nor possibly throws any
exception - (including RuntimeException!). This modifier would be very
useful in general, not just for OT/J.
Based on such modifier the compiler would check that guard predicates
and parameter mappings never call a non-pure method. So if you
want to do anything that could possible throw an exception, you'd
have to wrap it into a (perhaps static) method that handles the
exception. This enforces the rule-of-thumb: don't implement complex
algorithms in these places.

This should fully settle the issue in an ideal world. In RL, however,
two things are different: (a) Java doesn't have "pure", (b) pragmatically
in some situations you may want to relax the above discipline,
for convenience.

(a): Java really should support "pure" Smile, until then we can only check
the checked exceptions and remind the developer about the side-effects.
For guard predicates we introduced §5.4(b).

(b): Lazy developers may want to avoid an extra method just for handling
an exception. They probably want an exception in a guard to be interpreted
as "the guard evaluated to false". This option we added in §5.4(c).
The default is: exception thrown from a guard is a compile time error.
You may, however, lessen the severity to warning (or even ignore),
so that you'd just write @SuppressWarnings("exceptioninguard"),
which kind of buys you a default exception handler.

We haven't yet transferred this solution to parameter mappings,
which would be straight-forward for callin (exception simply aborts
triggering the callin, just like a guard predicate). However, for callout
the semantics of a tolerated exception is unclear. We can't just abort
a callout execution and continue as normal. But since it's the role
that declares the callout and is also the caller for these methods,
it seems natural that all exceptions raised in callout parameter mappings
must indeed be declared. For checked exceptions, that's what the
compiler enforces, e.g.,:
// declaration:
abstract void roleMethod(String s) throws Exception;
// binding:
void roleMethod(String s) -> void baseMethod(String s)
  with { dangerous(s) -> s }
// helper:
String dangerous (String s) throws Exception {
  return s.substring(4,12);
}


So, you can either propagate the exception, or handle it in the helper
method. So there should be all possible options to handle or propagate
exceptions to your liking. Even if some of these solutions may seem
more verbose than needed, the typical, frequent patterns are all very
concise, the extra verbosity only hits you in advanced situations,
which actually I rarely see in real OT/J code.

cheers,
Stephan

PS: You might also file a JSR to allow try-catch as an expression
(similar to "?:" instead of "if"), e.g.,
  return  s.substring(4,12) ?IndexOutOfBoundsException: "";

or some other syntax to that end. Smile
Re: A question on design motivation for callout syntax [message #515228 is a reply to message #514777] Thu, 18 February 2010 04:15 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Thanks for the explanations.

Stephan Herrmann wrote on Tue, 16 February 2010 10:46

...
Ideally, Java would support a method modifier - say - "pure" to mark
a method that neither causes a side effect nor possibly throws any
exception - (including RuntimeException!). This modifier would be very
useful in general, not just for OT/J.



This definition of pure methods sounds like "primeval" functions.

Stephan Herrmann wrote on Tue, 16 February 2010 10:46

PS: You might also file a JSR to allow try-catch as an expression
(similar to "?:" instead of "if"), e.g.,
  return  s.substring(4,12) ?IndexOutOfBoundsException: "";

or some other syntax to that end. Smile


Well, this sounds disputable.

BTW, Wiki mentions four languages with explicit role support. Do you know if there is a study on language comparison regarding to the role support implementations?

Regards,

Eugene

[Updated on: Thu, 18 February 2010 04:16]

Report message to a moderator

Re: A question on design motivation for callout syntax [message #515318 is a reply to message #515228] Thu, 18 February 2010 08:35 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 997
Registered: July 2009
Senior Member
Eugene Hutorny wrote on Thu, 18 February 2010 04:15

BTW, Wiki mentions four languages with explicit role support. Do you know if there is a study on language comparison regarding to the role support implementations?



Well, the folks who developed these four languages more or less know
each other and in scientific publications everyone has a few sentences
on the others but that won't help you much because it's mostly biased and
shallow.

Comprehensive comparison is hampered by the fact that documentation
is sparse and not all tools are available for download. So in my biased
assessment none of the other languages are near the maturity that is
needed for practical use.

Conceptually, however, these languages have indeed a lot in common.
All four of them implement roles as instances to be attached to a base
instance (IIRC). Three out of four support contexts as a container for
roles etc.

Among this group of languages at least two powerful concepts
are unique to Object Teams:

  • family polymorphism
  • implicit lifting and smart lifting


On a historical note: I've talked a lot to the people behind Chameleon.
These discussions led them to not further develop the language
(because they didn't want to compete with Object Teams which
had a bit of a head start), but rather Kasper Graversen's PhD came
to be a big taxonomy of approaches for implementing roles.
He used Object Teams as one of his examples, but not for assessing
Object Teams but for assessing his taxonomy Smile

BTW: I refrained from adding detailed discussion of Object Teams to
wikipedia, because they would probably consider that as undue
advertising of my own achievements. It might actually be a good
idea if an independent person would add maybe just one more
paragraph to the wiki article. Perhaps that would even trigger others
to write paragraphs about other languages so a comparison would
indeed develop within wikipedia. But realistically I doubt that sufficient
independent wiki authors exist - yet - for covering several approaches.
But who knows, why not use wikipedia as the independent platform it is?

cheers,
Stephan
Re: A question on design motivation for callout syntax [message #515337 is a reply to message #515318] Thu, 18 February 2010 09:14 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Thu, 18 February 2010 08:35

On a historical note: I've talked a lot to the people behind Chameleon.
These discussions led them to not further develop the language
(because they didn't want to compete with Object Teams which
had a bit of a head start), but rather Kasper Graversen's PhD came
to be a big taxonomy of approaches for implementing roles.
He used Object Teams as one of his examples, but not for assessing
Object Teams but for assessing his taxonomy Smile



Thanks for this reference, I have found his PhD on the inet, it looks impressive!

Re: A question on design motivation for callout syntax [message #515350 is a reply to message #515337] Thu, 18 February 2010 09:45 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 997
Registered: July 2009
Senior Member
Eugene Hutorny wrote on Thu, 18 February 2010 09:14
Thanks for this reference, I have found his PhD on the inet, it looks impressive!



Yes, from a research point of view this PhD is a significant achievement.
For practitioners it might be overwhelming to see all those options and
alternatives. That's why I emphasized the commonalities among approaches:
there's a lot of agreement which features a "good" role language should
actually support.

Stephan
Re: A question on design motivation for callout syntax [message #568358 is a reply to message #514417] Tue, 16 February 2010 10:46 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 997
Registered: July 2009
Senior Member
Quote:
> The only argument I can contrast - the subclass-to-role refactoring case.

Well, refactoring - just as everything related to evolution - is at the core of
our undertaking. A recent student's thesis on this topic is available in German
only, sorry. I'm thinking of where and how to give a complete account
of this topic. I think I will schedule this as an Eclipse article.


Quote:
> 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.
> Quote:
> > Yes, please expand on this


Actually, I see two related issues: exceptions and side effects.
OT/J introduces two places where the syntax calls for an expression,
not a block of statements: parameter mappings and guard predicates,
so I'd like to discuss both places together.

Ideally, Java would support a method modifier - say - "pure" to mark
a method that neither causes a side effect nor possibly throws any
exception - (including RuntimeException!). This modifier would be very
useful in general, not just for OT/J.
Based on such modifier the compiler would check that guard predicates
and parameter mappings never call a non-pure method. So if you
want to do anything that could possible throw an exception, you'd
have to wrap it into a (perhaps static) method that handles the
exception. This enforces the rule-of-thumb: don't implement complex
algorithms in these places.

This should fully settle the issue in an ideal world. In RL, however,
two things are different: (a) Java doesn't have "pure", (b) pragmatically
in some situations you may want to relax the above discipline,
for convenience.

(a): Java really should support "pure" :), until then we can only check
the checked exceptions and remind the developer about the side-effects.
For guard predicates we introduced http://www.objectteams.org/def/1.3/s5.html#s5.4.b

(b): Lazy developers may want to avoid an extra method just for handling
an exception. They probably want an exception in a guard to be interpreted
as "the guard evaluated to false". This option we added in http://www.objectteams.org/def/1.3/s5.html#s5.4.c
The default is: exception thrown from a guard is a compile time error.
You may, however, lessen the severity to warning (or even ignore),
so that you'd just write @SuppressWarnings("exceptioninguard"),
which kind of buys you a default exception handler.

We haven't yet transferred this solution to parameter mappings,
which would be straight-forward for callin (exception simply aborts
triggering the callin, just like a guard predicate). However, for callout
the semantics of a tolerated exception is unclear. We can't just abort
a callout execution and continue as normal. But since it's the role
that declares the callout and is also the caller for these methods,
it seems natural that all exceptions raised in callout parameter mappings
must indeed be declared. For checked exceptions, that's what the
compiler enforces, e.g.,:
// declaration:
abstract void roleMethod(String s) throws Exception;
// binding:
void roleMethod(String s) -> void baseMethod(String s)
with { dangerous(s) -> s }
// helper:
String dangerous (String s) throws Exception {
return s.substring(4,12);
}


So, you can either propagate the exception, or handle it in the helper
method. So there should be all possible options to handle or propagate
exceptions to your liking. Even if some of these solutions may seem
more verbose than needed, the typical, frequent patterns are all very
concise, the extra verbosity only hits you in advanced situations,
which actually I rarely see in real OT/J code.

cheers,
Stephan

PS: You might also file a JSR to allow try-catch as an expression
(similar to "?:" instead of "if"), e.g.,

return s.substring(4,12) ?IndexOutOfBoundsException: "";
or some other syntax to that end. :)
Re: A question on design motivation for callout syntax [message #568423 is a reply to message #568358] Thu, 18 February 2010 04:15 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Thanks for the explanations.

Stephan Herrmann wrote on Tue, 16 February 2010 10:46
> ...
> Ideally, Java would support a method modifier - say - "pure" to mark
> a method that neither causes a side effect nor possibly throws any
> exception - (including RuntimeException!). This modifier would be very
> useful in general, not just for OT/J.


This definition of pure methods sounds like "primeval" functions.

Stephan Herrmann wrote on Tue, 16 February 2010 10:46
> PS: You might also file a JSR to allow try-catch as an expression
> (similar to "?:" instead of "if"), e.g.,
>
> return s.substring(4,12) ?IndexOutOfBoundsException: "";
> or some other syntax to that end. :)

[/quote]

Well, this sounds disputable.

BTW, http://en.wikipedia.org/wiki/Role-oriented_programming mentions four languages with explicit role support. Do you know if there is a study on language comparison regarding to the role support implementations?

Regards,

Eugene
Re: A question on design motivation for callout syntax [message #568474 is a reply to message #568423] Thu, 18 February 2010 08:35 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 997
Registered: July 2009
Senior Member
Eugene Hutorny wrote on Thu, 18 February 2010 04:15
> BTW, Wiki mentions four languages with explicit role support. Do you know if there is a study on language comparison regarding to the role support implementations?


Well, the folks who developed these four languages more or less know
each other and in scientific publications everyone has a few sentences
on the others but that won't help you much because it's mostly biased and
shallow.

Comprehensive comparison is hampered by the fact that documentation
is sparse and not all tools are available for download. So in my biased
assessment none of the other languages are near the maturity that is
needed for practical use.

Conceptually, however, these languages have indeed a lot in common.
All four of them implement roles as instances to be attached to a base
instance (IIRC). Three out of four support contexts as a container for
roles etc.

Among this group of languages at least two powerful concepts
are unique to Object Teams:

family polymorphism
implicit lifting and smart lifting


On a historical note: I've talked a lot to the people behind Chameleon.
These discussions led them to not further develop the language
(because they didn't want to compete with Object Teams which
had a bit of a head start), but rather Kasper Graversen's PhD came
to be a big taxonomy of approaches for implementing roles.
He used Object Teams as one of his examples, but not for assessing
Object Teams but for assessing his taxonomy :)

BTW: I refrained from adding detailed discussion of Object Teams to
wikipedia, because they would probably consider that as undue
advertising of my own achievements. It might actually be a good
idea if an independent person would add maybe just one more
paragraph to the wiki article. Perhaps that would even trigger others
to write paragraphs about other languages so a comparison would
indeed develop within wikipedia. But realistically I doubt that sufficient
independent wiki authors exist - yet - for covering several approaches.
But who knows, why not use wikipedia as the independent platform it is?

cheers,
Stephan
Re: A question on design motivation for callout syntax [message #568497 is a reply to message #568474] Thu, 18 February 2010 09:14 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Thu, 18 February 2010 08:35
> On a historical note: I've talked a lot to the people behind Chameleon.
> These discussions led them to not further develop the language
> (because they didn't want to compete with Object Teams which
> had a bit of a head start), but rather Kasper Graversen's PhD came
> to be a big taxonomy of approaches for implementing roles.
> He used Object Teams as one of his examples, but not for assessing
> Object Teams but for assessing his taxonomy :)


Thanks for this reference, I have found his PhD on the inet, it looks impressive!
Re: A question on design motivation for callout syntax [message #568518 is a reply to message #568497] Thu, 18 February 2010 09:45 Go to previous message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 997
Registered: July 2009
Senior Member
Eugene Hutorny wrote on Thu, 18 February 2010 09:14
> Thanks for this reference, I have found his PhD on the inet, it looks impressive!


Yes, from a research point of view this PhD is a significant achievement.
For practitioners it might be overwhelming to see all those options and
alternatives. That's why I emphasized the commonalities among approaches:
there's a lot of agreement which features a "good" role language should
actually support.

Stephan
Previous Topic:Multidispatch pattern with OT/J
Next Topic:IDE for a language embedded in Java
Goto Forum:
  


Current Time: Thu Aug 28 05:33:24 EDT 2014

Powered by FUDForum. Page generated in 0.02170 seconds