Zusammenhangskomponenten wieder löschen, da diese bereits in Sourcefile gebildet werden und sie daher hier nichts mehr bringen
Lösungsidee:
Schritt 4, Teil 1 sollte als Ergbenis ein ODER-Constraint gebeldet werden.
Die Bildung des Cart.Produkt sollte dann mit den gleichen Optimierungen (ATPS-Paper) gebildet werden.
In TypeExpr in Lambdaexpression soll folgendes eingefügt werden:
Fun<? ext rTy, ? super argTy> (x) -> f(x),
wenn x:argTy oder x:? super argTy und wenn f(x):rTy oder f(x): ? extends…
Folgendes wird implementiert in TypeExpr in Lambdaexpression:
FunN<? ext rTy, ? super argTy> (x) -> g(x)
argTy der Typ von x ist und wenn g(x): rTy oder g(x): ? ext rTy
bei g(x): ? super …
Code ist noch vollendet.
Sollte noch vollendet werden.
Lässt sich mit Zussammenhangskomponenten nicht lösen.
Ich denke hier ist an der falschen Stelle in TYPEExpr das ODER-Constraint eingefügt worden.
Es sollte bei FunN<? Ext Ty, ? Super TY'> oder FunN<Ty, TY'> nicht bei den Argumenten eingefügt we…
LambdaTest4:
class LambdaTest{
Fun1<String, String> op = (var) -> { var2; var2 = var; return var; };
}
kommt auch dieses Problem zu tragen.
class BoundedGenericTest{ String var = "test"; B methode(){ return var; } }
ist kein korrektes Java,
java.lang.String <. BoGTV B (extends String) ist fa…
2.Schritt von TUnify ergibt
[ (TPH R1860513229 <. TPH ABJ), (TPH B <. Fun2< TPH R1860513229, TPH T11860513229, TPH T21860513229 >), (LambdaTest< GTV A, GTV B > <. TPH T11860513229), (TPH …
Das eigentliche Problem ist, dass bei ? ext/super TYPE alles Type's eingesetzt werden dürfen. Man sollte eine Superklasse für alle Klasse einführen, die als TYPE vorkomen dürfen. Dann könnte …
TPH C <. ? super java.lang.String wird zurückgeführt auf TPH C <. java.lang.String
TPH C <. ? extends java.lang.String läuft in einen neu eingefügten Fehlerfall, da keine Lösung
War ein Fehler im TUnify.
Der Fall Typ <. GTV war nicht berücksichtigt worden. Deshalb wurde der Constraint gelöscht.