forked from JavaTX/JavaCompilerCore
51 lines
1.7 KiB
Plaintext
51 lines
1.7 KiB
Plaintext
- Was sind / wofür brauch man TTO und Classes
|
|
- Unify löst auch zirkuläre Abhängigkeiten a <. b <. c <. a
|
|
- Tests dazu?
|
|
- Prüfung im Builder?
|
|
|
|
- Unterschied Wildcard und FreshWildcard, ExtendsWildcard und FreshExtendsWildcard etc...
|
|
- FreshWildcard = TPH für Wildcards?
|
|
|
|
- Warum ist result von unify = Menge<Menge<Pair>> und nicht Menge<Pair>
|
|
|
|
- Menge Equals überarbeiten (Momentan Reihenfolgensensitiv)
|
|
|
|
- Wie kommen die Mengen des Unify-Algorithmus zustande? Siehe test:
|
|
/*
|
|
* Test b <. a, a <. b
|
|
*/
|
|
|
|
-
|
|
|
|
|
|
- Transitiven Abschluss von FC bilden um schneller Subtypen bestimmen zu können
|
|
- Problem: 2 FCs für Pairs und MPairs durch das Mapping
|
|
- Equals der Typen schreiben um instanceof Prüfungen zu vermeiden
|
|
|
|
- Refactoring der Klassen Menge und Pair erlaubt?
|
|
++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
|
Instanceof wird verwendet da:
|
|
-> Entscheidung für diese Lösung, da 2-Fach-Visitor oder DoubleDispatch Pattern
|
|
enorm viele überladene Methoden zur folge hätten, nicht intuitiv wären und die rules in die Typen verschoben hätten.
|
|
|
|
Gilt reduce für alle Typen oder nur für simple und tphs? (Vermutlich nur s und tph sonst bräuchte man keine upLow regel)
|
|
|
|
+++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
HashCode implementierungen testen (type paramerte mit einbeziehen, hashcodes cachen -> da immutable)
|
|
|
|
|
|
+++++++++++++++++++++++++++++++++++++++++++++++
|
|
- Typen sind anhand ihres identifiers durchgängig identifizierbar
|
|
|
|
- ReduceEq nur auf SimpleTypes oder auf alles anwenden? (Momentan alles)
|
|
- ReduceEq Permutation?
|
|
|
|
EED UP
|
|
- Anwendungsreihenfolge der Regeln (wahrscheinlichste zuerst, evtl ist nach regel 1 regel 2 nie möglich etc...)
|
|
- Erase vor Reduce
|
|
- Rechenarm vor rechenintensiv
|
|
|