Warum schlägt die Inferenz hier fehl?

8

Also habe ich diesen relativ einfachen Code gemacht, und weder ich noch IntelliJ IDEA sehen etwas falsch daran, aber Javac klettert über die markierte Zeile und klagt, dass er nicht auf die Typen schließen kann:

%Vor%

Das Teilen der problematischen Linie in 2 mit expliziten Typen hilft, aber die Typensignatur ist länger als das Lambda, was den Zweck des Schreibens des Lambda an erster Stelle komplett zunichte macht ...

BEARBEITEN: Wenn ich anstelle einer Methodenreferenz ein tatsächliches Lambda verwende, bekomme ich das Problem erneut. Sehen Sie sich die neu hinzugefügte Methode oben an.

    
kaqqao 30.01.2018, 00:35
quelle

2 Antworten

7

javac mag nicht, dass DefaultEdge ein unformatierter Typ ist.

%Vor%

funktioniert wie erwartet.

    
Jeffrey 30.01.2018, 00:44
quelle
4

Beachten Sie neben Jeffreys Antwort , dass sich Ihre EdgeCreator -Schnittstelle nicht von Function in ihrer unterscheidet Funktionalität und createEdges benötigt nicht unbedingt die problematischen Typenbeschränkungen. Eine Lösung besteht also darin, EdgeCreator extendieren Function zu vereinfachen createEdges .

%Vor%

Sie können auch die EdgeCreator -Schnittstelle entfernen und Function<N, E extends Edge<N>> an Stellen verwenden, an denen die Einschränkung erzwungen werden muss. In diesem Code gibt es jedoch keinen solchen Ort. Die Einschränkung wird immer noch erzwungen, wenn jemand createEdges(List,Function) bzw. sein Ergebnis in einem Kontext, in dem ein List<Edge<SpecificNodeType>> benötigt wird.

Wenn Sie die Typenzwänge über zu viele Code-Positionen tragen, wird Ihr Quellcode ohne Nutzen aufgebläht.

Übrigens brauchen Sie in Ihrem aktuellen Code nicht einmal die Klasse DefaultEdge ; Sie könnten den gesamten Code nach

vereinfachen %Vor%     
Holger 30.01.2018 07:59
quelle