Home » Language IDEs » Objectteams » What are the origins of value bound classes?
|
| Re: What are the origins of value bound classes? [message #568536 is a reply to message #568460] |
Thu, 18 February 2010 15:50   |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
OK, for some more history :)
From the very beginning, OT/J supported "family polymorphism", which
was presented by Erik Ernst at ECOOP 2001. I'm very happy that Erik
actually receives this year's http://www.aito.org/Dahl-Nygaard/2010.html!!
Family polymorphism is one of the contributions he is being recognised for.
Lang before, dependent types have being discussed in programming language
theory, but only with family polymorphism the heavy-weight concept of
dependent types became smoothly applicable in practice.
Now with family polymorphism in OT/J each role class implicitly depends
on the enclosing team instance. This gives type safety to, e.g., the double
dispatch pattern being discussed in another thread. One cool thing about
this is, that normally, you don't see how sophisticated the type system is,
because type anchors remain implicit:
public team class ATeam {
protected class ARole {
}
ARole role1;
ARole<@this> role2;
}
Here both fields are declared with the exact same type,
only role2 makes explicit that the type depends on the team instance,
whereas role1 uses the same implicitly.
Erik Ernst has his own implementation of family polymorphism in his
language gbeta. The major difference at this step was to apply his
concept to a role language, which gbeta is not. On another historical
note: it was either Mira Mezini or Klaus Ostermann who actually
introduced me to Erik, so the four of us were discussing these things
in various situations. Mira and Klaus were working on a language called
CaesarJ that combined many of the same concepts as OT/J. I haven't heard
about CaesarJ for some years now, so that project might have stalled.
Originally the syntax for role types was like aTeam.Role rather than
Role<@aTeam>, but that was actually in times before Java had generics.
With Java 5 we decided to migrate this syntax in order to better
integrate with the new syntax for generics. The mailto:'@' was introduced
to distinguish between parameters that are types and parameters that
are values.
When we were working on an OT/J case study, it occurred that applying
such parameterization only to roles wouldn't suffice for some advanced
situations. We had a team as a facade to the database, with roles for each
entity type. In that application some derived data objects would be passed
around that somehow related to those entity roles. But we didn't find a way
of expressing the connection to the facade team instance within the data
objects, so we couldn't pass any information back into the database team.
At that point I introduced the option to also let regular (non-role) classes
depend on an instance. A terse sketch looks like this
public team class DBFacade {
public class Article { ... }
public void removeArticle(Article a) { ... }
}
public class ArticleStatistics <DBFacade theDB> {
public Article<@theDB> article;
public int numSold;
}
public class StatisticsComputation<DBFacade theDB> {
public ArticleStatistics<@theDB> getSlowestArticle() { ... }
}
...
void discountSlowMover(final DBFacade theDB) {
StatisticsComputation<@theDB> comp = new StatisticsComputation<@theDB>();
ArticleStatistics<@theDB> stats = comp.getSlowestArticle();
theDB.removeArticle(stats.article);
}
What's happening is: I let the StatisticsComputer extract from the
DB the article with lowest sales. The article gets passed around
from DBFacade to StatisticsComputer to ArticleStatistics
and back to the DBFacade. In all this round trip the information
from which instance of DBFacade the Article originated is preserved.
This means, the type checker ensures that DBFacade can be used
as a representation for a DB transaction and the type checker will
guarantee that any entity will only be used in its original transaction!
Conceptually, this is only a mild generalization of what we already had
for roles, just making it a bit more explicit so it can be used for non-role
classes, too. Luckily, we didn't have to invent new rules for the
type checker, because extending family polymorphism to general
value dependent types is mostly a representational issue.
So, my pride is not in inventing dependent types or any of that sort,
but in combining best-of-the-breed theory into a real practical languge.
So for the soundness of the theory I can rely on famous people like
Erik Ernst, while we provide an implementation that really works and
is more complete than what research prototypes can possibly achieve.
From the point of view of an OT/J novice, value dependent types may
appear quite exotic, and I'm sure you can do lots of useful things in OT/J
without knowing about this concept. However, if you consistently apply
OT/J for your design, there might be situations, where you'll have to use
extra smartness. For those situations we included all the tools needed,
so the developer will not find herself left on her own, but we'll support
her even in complex situations.
OT/J is not that kind of virtual reality where you drive a street and all
the sudden find that the street doesn't render any further because you've
reached the end of the modelled world. At least that's our goal :)
happy driving
Stephan
|
|
| |
| Re: What are the origins of value bound classes? [message #568641 is a reply to message #568583] |
Fri, 19 February 2010 14:43 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Eugene Hutorny wrote on Fri, 19 February 2010 05:40
> One thing which is not clear fro me yet - how value bound classes help to implement the family polymorphism?
> What unsolvable problems would exist if OT/J had no value bound classes ?
My favorite example in this regard is a "product line" for board games:
an abstract team BoardGame with roles like Player, Token, Move, Rule...
(all roles are unbound, i.e., no playedBy, in this excercise).
Roles interact through methods like Rule.checkMove(Token t, Move m).
Next derive a few concrete games from BoardGame, like Go, Chess ...
Now consider the role Rule in team Go, and its method checkMove:
Certainly the role may expect a Go Token and a Go Move, because
that's the only things it can check. However the signature of checkMove
only says "(Token t, Move m)". With a plain type system it would be easy
to have a Chess Queen chasing all over the Go board, and the checkMove
method is most likely to just explode at runtime (with no indication of
this at compile time).
With family polymorphism we are smarter. We know that types are to
be seen relative to the current context. So we know that Token actually
means Token<@BoardGame.this>, i.e., a token from the enclosing
board game team instance. The type Token implicitly depends on the
enclosing team instance (value dependent type). As mentioned, you
only actually see this, if you pass a role to the outside ("externalized role"),
then you will need to explicitly say Token<@myGoGame> or
Token<@yourChessGame> and the typechecker will not allow you
taking a token from myGoGame and inserting it into yourChessGame.
Summarizing: only with value dependent types it is possible to avoid
the Queen going berserk on a Go board by detecting violations already
at compile time. Put differently: if you allow overriding of nested classes
(aka "virtual classes") the result may be unexpected (is not type safe)
unless you use dependent types to ensure consistency.
Does this answer your question?
Stephan
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 15:38:31 GMT 2024
Powered by FUDForum. Page generated in 0.01801 seconds |
] 
Search
Help
Register
Login
Home
