Nachbildung Scala-Phantom-Typen mit Java-Generics (Imitation of Scala Phantom Types with Java Generics)

[Heiner Kücker]

Hallo Java-Freunde,

ihr wisst sicher, womit ich mich beschäftige
(schaut mal 11 Threads weiter unten)

Es geht um Fehlervermeidung in Java-Programmen.

Eine Vorbild-Lösung sind die Phantom-Typen von Scala.

Leider funktioniert der von Patrick Roemer
gepostete Link nicht mehr:

http://blog.vasilrem.com/tic-tac-toe-api-with-phantom-types


Meine Lösung

http://heinerkuecker.de/ConstraintCodeGenerator.html

http://control-and-command.de/zip/CONSTRAINT_CODE_GENERATOR.zip
(Verzeichnis im Zip:
14_TRANSFORM_SAFEOPERATION_TIC_TAC_TOE und
15_DYNAMIC_TRANSFORM_SAFEOPERATION_TIC_TAC_TOE)

leidet unter kombinatorischer Explosion.


Die Scala-Lösung arbeitet mit Typ-Parametern.


Ein einfacheres Beispiel findet sich unter

http://james-iry.blogspot.de/2010/10/phantom-types-in-haskell-and-scala.html

Eine Rakete benötigt Treibstoff und Sauerstoff
ehe sie gestartet werden kann.

Es gibt zwei jeweils zwei binäre Unter-Zustände

Treibstoff: ja/nein
Sauerstoff: ja/nein

Gestartet werden kann nur wenn Treibstoff und
Sauerstoff getankt wurden.

Mehrmals tanken ist nicht möglich.

Die Reihenfolge des Tankens
(Treibstoff - Sauerstoff, Sauerstoff - Treibstoff)
ist egal.

Das ergibt vier Permutationen, also bei meiner
Lösung vier konkrete Constraint-Klassen.


Statische Methoden in Java können einen
eigenen Gültigkeitsbereich für Typ-Parameter
aufspannen.

So kann man eine statische Methode definieren,
die einen Typ-Parameter konkret festlegt,
Ausprägung Eingabe ungleich zu Ausprägung
Ausgabe, welcher die Zustandsänderung
abbildet, und beliebig viele andere
Typ-Parameter, welche anonym behandelt
werden, Ausprägung Eingabe gleich Ausprägung
Ausgabe, welche die ignorierten ungeänderten
Zustände einfach durchleiten.

Ich habe dies mal probeweise implementiert.

http://control-and-command.de/zip/CONSTRAINT_CODE_GENERATOR.zip

(Verzeichnis im Zip:
99_IMITATE_SCALA_PHANTOM_TYPES_WITH_JAVA_GENERICS)


In diesem Schwung habe ich gleich mal
mit dem Tic-Tac-Toe-Beispiel weitergemacht.

Der Compiler soll absichern, dass nur
erlaubte Züge (Setzungen) möglich sind.

Die Wechsel der Spieler habe ich mit
dem Interface Oppositor abgebildet,
dies ist sicher in Richtung Zustands-
Automat ausbaufähig.

Da ich nur statische Methoden benutzen
kann, ist die Notation umgekehrt zur
Notation mit nichtstatischen Methoden;
ist nicht besonders lesbar.

Den Abbruch des Spieles beim Erreichen
eines Gewinn- oder Unentschieden-Zustandes
kann ich so leider nicht abbilden.

Die neun set-Methoden sind trotzdem
noch eine Menge Schreibarbeit.

Könnte man da was sparen?

Eventuell generieren?

Habt Ihr Ideen zur Verbesserung?

Kann man sowas praktisch verwenden?

Grüsse
Heiner Kücker

[Claus Reibenstein]

Heiner Kï¿œcker schrieb:

> ihr wisst sicher, womit ich mich beschï¿œftige

> (schaut mal 11 Threads weiter unten)

Das ist eine _sehr_ genaue Angabe. Zumal sich "weiter unten" bis jetzt
kein einziger Thread befindet ...

Message-ID wï¿œre sinnvoller gewesen.

Gruￜ
Claus

[Heiner Kücker]

Claus Reibenstein schrieb:

Schau mal auf
https://groups.google.com/forum/#!topic/de.comp.lang.java/fv220rUonn8

Der Link funktioniert aber nicht im Internet Explorer

>
> Gruￜ
> Claus

Grüsse
Heiner

[Heiner Kücker]

Heiner Kücker schrieb:

> Hallo Java-Freunde,
> ihr wisst sicher, womit ich mich beschäftige
>

> Es geht um Fehlervermeidung in Java-Programmen.
> Eine Vorbild-Lösung sind die Phantom-Typen von Scala.

Ich habe einen Link mit einer ähnlichen Lösung gefunden:

http://gabrielsw.blogspot.de/2012/09/phantom-types-in-java.html

> Grüsse
>
> Heiner Kücker