Warum ist diese Typrückschluss funktioniert nicht mit dieser Lambda-Ausdruck Szenario?

Ich habe ein seltsames Szenario, in dem Typrückschluss funktioniert nicht, da würde ich erwarten, dass bei der Verwendung eines lambda-Ausdrucks. Hier ist eine Annäherung an meine real-Szenario:

static class Value<T> {
}

@FunctionalInterface
interface Bar<T> {
  T apply(Value<T> value); //Change here resolves error
}

static class Foo {
  public static <T> T foo(Bar<T> callback) {
  }
}

void test() {
  Foo.foo(value -> true).booleanValue(); //Compile error here
}

Die compile-Fehler bekomme ich auf der zweiten bis letzten Zeile ist

Die Methode booleanValue() ist nicht definiert für den Typ Objekt

wenn ich warf die lambda Bar<Boolean>:

Foo.foo((Bar<Boolean>)value -> true).booleanValue();

oder wenn ich ändern Sie die Signatur der Methode von Bar.apply raw-Typen:

T apply(Value value);

dann das problem verschwindet. Die Art und Weise würde ich erwarten, dass dies funktioniert ist, dass:

  • Foo.foo nennen sollte schließen, ein Rückgabetyp boolean
  • value im lambda sollte geschlossen werden, um Value<Boolean>.

Warum nicht diese Schlußfolgerung funktioniert wie erwartet und wie kann ich dies ändern API machen, damit es funktioniert, wie erwartet?

  • Welche Java-Version Sie verwenden?
  • Java 1.8.0_25
  • Sie haben einfach ein "type mismatch", weil Boolean ist nicht ein Wert<Boolean>. Wie der compiler sollte in der Lage sein zu wissen, dass T einen Wert<T>? Und natürlich ist es auch nicht wissen, wie es ausgegangen Objekt. Blick auf die Funktion Interface-Methode anwenden. Wert ist eine konkrete Art, die in Zusammenhang mit Ihrem Bar-Schnittstelle.
  • Ich denke, das was du beschreibst ist die Grundlage für @fukanchik die Antwort von unten. Das problem dort ist, dass der compiler folgert Value<Object> statt Value<Boolean> das ist, was ich bin nach. Bitte fühlen Sie sich frei zu teilen irgendwelche Ideen auf, wie man es an die Arbeit.
  • Ich habe ein update gemacht auf meine Antwort, können Sie einen Blick zu haben.
  • Was ist, wenn Sie Boolean.TRUE statt true?
  • Keine änderung
  • Wenn Sie nicht wegwerfen der Rückgabetyp Foo.foo, die compiler nutzen könnte, der Zieltyp abgeleitet Schranken für T...
  • Auch ohne das Ziel geben, kann man visuell ableiten, welche den Rückgabetyp und die lambda-parameter geben sollte - was ich so erwartet, richtig?
  • Leider Typrückschluss ist nicht Gedankenlesen; es ist constraint solving. Die Frage ist also, Woher weiß der compiler, um seine Einschränkungen aus. Die lambda-Körper wird nicht verwendet, um generieren Einschränkungen (aus guten Gründen.) So, während es ist "offensichtlich", dass Sie meinte, dass T=boolean ist, dass die lambda-returns-boolean ist nicht als Eingang verwendet in Typ-Inferenz. Also Nein, der compiler hat nicht die notwendigen Informationen ableiten, dass T in diesem Fall mit dem return-type ignoriert.
  • Wenn der compiler nicht die lambda-Körper zu erzeugen Zwänge, warum dann nicht ändern Bar Verwendung einer raw - Value Art etwas ändern?
  • Raw-Typen sind viral. So dass die änderung der Signatur von apply (), um ein raw-Typ Ursachen der Inferenz zur Behandlung der lambda als roh-und jetzt, aus der Sicht der Inferenz, T erscheint nicht überall, so gibt es nichts zu folgern.
  • Ich bin mir nicht sicher, ob ich verstehe deine Erklärung. Wenn es nichts zu folgern, wie weiß der compiler magisch kommen mit Boolean als Typ für T wenn es instanziiert die Methode Signatur? Sieht es denn an der lambda-Körper in diesem Fall, oder ist etwas anderes passiert?

InformationsquelleAutor Josh Stone | 2015-07-05
  1. 31

    Unter der Haube

    Über einige versteckte javac Funktionen, können wir mehr Informationen bekommen über das, was passiert:

    $ javac -XDverboseResolution=deferred-inference,success,applicable LambdaInference.java 
LambdaInference.java:16: Note: resolving method foo in type Foo to candidate 0
    Foo.foo(value -> true).booleanValue(); //Compile error here
       ^
  phase: BASIC
  with actuals: <none>
  with type-args: no arguments
  candidates:
      #0 applicable method found: <T>foo(Bar<T>)
        (partially instantiated to: (Bar<Object>)Object)
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: Deferred instantiation of method <T>foo(Bar<T>)
    Foo.foo(value -> true).booleanValue(); //Compile error here
           ^
  instantiated signature: (Bar<Object>)Object
  target-type: <none>
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: error: cannot find symbol
    Foo.foo(value -> true).booleanValue(); //Compile error here
                          ^
  symbol:   method booleanValue()
  location: class Object
1 error

    Dies ist eine Menge von Informationen, lassen Sie uns es brechen.

    LambdaInference.java:16: Note: resolving method foo in type Foo to candidate 0
    Foo.foo(value -> true).booleanValue(); //Compile error here
       ^
  phase: BASIC
  with actuals: <none>
  with type-args: no arguments
  candidates:
      #0 applicable method found: <T>foo(Bar<T>)
        (partially instantiated to: (Bar<Object>)Object)
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)

    phase: Methode Anwendbarkeit phase

    aktuelle Werte: der tatsächliche Argumente übergeben

    Typ-args: explizite Typ-Argumente

    Kandidaten: potenziell anwendbare Methoden

    ist-Werte ist <none> weil unsere implizit typisierte lambda ist nicht passend zur Anwendbarkeit.

    Der compiler löst Ihr Aufruf foo die einzige Methode namens foo im Foo. Es wurde teilweise instanziiert, um Foo.<Object> foo (da gab es keine Werte oder Typ-Argumente), aber das kann sich ändern, an der deferred-Inferenz Bühne.

    LambdaInference.java:16: Note: Deferred instantiation of method <T>foo(Bar<T>)
    Foo.foo(value -> true).booleanValue(); //Compile error here
           ^
  instantiated signature: (Bar<Object>)Object
  target-type: <none>
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)

    instanziiert Signatur: die vollständig instanziiert Unterschrift foo. Es ist das Ergebnis von diesem Schritt (zu diesem Zeitpunkt keine mehr geben Rückschluss auf die Signatur von foo).

    Ziel-Art: der Kontext, der Anruf wird gemacht. Wenn die Methode-Aufruf ist ein Teil einer Aufgabe ist, wird es die linke Seite. Wenn der Methodenaufruf ist selbst Teil eines Methodenaufrufs, es wird der parameter-Typ.

    Da Ihre Methode invocation ist freistehend, es gibt keine Gegner-Typ. Da gibt es kein target-Typ, keine weitere Folgerung gemacht werden kann, auf foo und T abgeleitet werden Object.

    Analyse

    Den compiler nicht implizit typisierte Lambda-Ausdrücke, die während der Inferenz. Bis zu einem gewissen Grad ist dies sinnvoll. Im Allgemeinen, gegeben param -> BODY Sie werden nicht in der Lage zu kompilieren BODY bis Sie einen Typ für param. Wenn Sie nicht versuchen, zu folgern, die Art für param aus BODY, es führen könnte, um eine Huhn-und-ei-problem geben. Es ist möglich, dass einige Verbesserungen vorgenommen werden, ist dies in zukünftigen Versionen von Java.

    Lösungen

    Foo.<Boolean> foo(value -> true)

    Diese Lösung stellt eine explizite Typ-argument zu foo (Hinweis: die with type-args Abschnitt unten). Dies ändert die partielle Instanziierung der Methode Signatur (Bar<Boolean>)Boolean, das ist, was Sie wollen.

    LambdaInference.java:16: Note: resolving method foo in type Foo to candidate 0
    Foo.<Boolean> foo(value -> true).booleanValue(); //Compile error here
       ^
  phase: BASIC
  with actuals: <none>
  with type-args: Boolean
  candidates:
      #0 applicable method found: <T>foo(Bar<T>)
        (partially instantiated to: (Bar<Boolean>)Boolean)
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: resolving method booleanValue in type Boolean to candidate 0
    Foo.<Boolean> foo(value -> true).booleanValue(); //Compile error here
                                    ^
  phase: BASIC
  with actuals: no arguments
  with type-args: no arguments
  candidates:
      #0 applicable method found: booleanValue()

    Foo.foo((Value<Boolean> value) -> true)

    Diese Lösung explizit Typen lambda, die es ermöglicht, zielgerichtet auf Anwendbarkeit (Hinweis: with actuals unten). Dies ändert die partielle Instanziierung der Methode Signatur (Bar<Boolean>)Boolean, das ist, was Sie wollen.

    LambdaInference.java:16: Note: resolving method foo in type Foo to candidate 0
    Foo.foo((Value<Boolean> value) -> true).booleanValue(); //Compile error here
       ^
  phase: BASIC
  with actuals: Bar<Boolean>
  with type-args: no arguments
  candidates:
      #0 applicable method found: <T>foo(Bar<T>)
        (partially instantiated to: (Bar<Boolean>)Boolean)
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: Deferred instantiation of method <T>foo(Bar<T>)
    Foo.foo((Value<Boolean> value) -> true).booleanValue(); //Compile error here
           ^
  instantiated signature: (Bar<Boolean>)Boolean
  target-type: <none>
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: resolving method booleanValue in type Boolean to candidate 0
    Foo.foo((Value<Boolean> value) -> true).booleanValue(); //Compile error here
                                           ^
  phase: BASIC
  with actuals: no arguments
  with type-args: no arguments
  candidates:
      #0 applicable method found: booleanValue()

    Foo.foo((Bar<Boolean>) value -> true)

    Gleiche wie oben, aber mit einem etwas anderen Geschmack.

    LambdaInference.java:16: Note: resolving method foo in type Foo to candidate 0
    Foo.foo((Bar<Boolean>) value -> true).booleanValue(); //Compile error here
       ^
  phase: BASIC
  with actuals: Bar<Boolean>
  with type-args: no arguments
  candidates:
      #0 applicable method found: <T>foo(Bar<T>)
        (partially instantiated to: (Bar<Boolean>)Boolean)
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: Deferred instantiation of method <T>foo(Bar<T>)
    Foo.foo((Bar<Boolean>) value -> true).booleanValue(); //Compile error here
           ^
  instantiated signature: (Bar<Boolean>)Boolean
  target-type: <none>
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: resolving method booleanValue in type Boolean to candidate 0
    Foo.foo((Bar<Boolean>) value -> true).booleanValue(); //Compile error here
                                         ^
  phase: BASIC
  with actuals: no arguments
  with type-args: no arguments
  candidates:
      #0 applicable method found: booleanValue()

    Boolean b = Foo.foo(value -> true)

    Diese Lösung stellt eine explizite Zielgruppe für Ihre Methode aufrufen (siehe target-type unten). Dies ermöglicht es der latente-Instanziierung zu folgern, dass die Typ-parameter werden sollte Boolean statt Object (siehe instantiated signature unten).

    LambdaInference.java:16: Note: resolving method foo in type Foo to candidate 0
    Boolean b = Foo.foo(value -> true);
                   ^
  phase: BASIC
  with actuals: <none>
  with type-args: no arguments
  candidates:
      #0 applicable method found: <T>foo(Bar<T>)
        (partially instantiated to: (Bar<Object>)Object)
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: Deferred instantiation of method <T>foo(Bar<T>)
    Boolean b = Foo.foo(value -> true);
                       ^
  instantiated signature: (Bar<Boolean>)Boolean
  target-type: Boolean
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)

    Haftungsausschluss

    Dies ist das Verhalten, das auftreten. Ich weiß nicht, ob dies ist, was angegeben ist in der JLS. Ich könnte Graben um und sehen, ob ich finden konnte, der genaue Abschnitt, der angibt, dieses Verhalten, aber Typ-Inferenz notation gibt mir Kopfschmerzen.

    Diese auch nicht vollständig erklären, warum ändern Bar Verwendung einer raw - Value würde dieses Problem lösen:

    LambdaInference.java:16: Note: resolving method foo in type Foo to candidate 0
    Foo.foo(value -> true).booleanValue();
       ^
  phase: BASIC
  with actuals: <none>
  with type-args: no arguments
  candidates:
      #0 applicable method found: <T>foo(Bar<T>)
        (partially instantiated to: (Bar<Object>)Object)
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: Deferred instantiation of method <T>foo(Bar<T>)
    Foo.foo(value -> true).booleanValue();
           ^
  instantiated signature: (Bar<Boolean>)Boolean
  target-type: <none>
  where T is a type-variable:
    T extends Object declared in method <T>foo(Bar<T>)
LambdaInference.java:16: Note: resolving method booleanValue in type Boolean to candidate 0
    Foo.foo(value -> true).booleanValue();
                          ^
  phase: BASIC
  with actuals: no arguments
  with type-args: no arguments
  candidates:
      #0 applicable method found: booleanValue()

    Für einige Grund, es zu verändern verwenden Sie eine raw - Value ermöglicht die verzögerte Instanziierung zu folgern, dass T ist Boolean. Wenn ich zu spekulieren, würde ich vermuten, dass, wenn der compiler versucht, passen die lambda die Bar<T> es kann daraus schließen, dass T ist Boolean durch den Blick auf den Körper des lambda-Ausdrucks. Dies bedeutet, dass meine früheren Analyse ist falsch. Der compiler kann ausführen, Typ-Inferenz, die auf dem Körper des einen lambda-Ausdruck, sondern nur auf den Typ von Variablen, die nur erscheinen in der Rückgabetyp.

    InformationsquelleAutor Jeffrey
  2. 5

    Ableitung auf lambda-parameter-Typ kann hängt von der lambda-Körper.

    Den compiler Gesichter ein harter job und versuche den Sinn der impliziten lambda-Ausdrücke

        foo( value -> GIBBERISH )

    Den Typ der value abgeleitet werden muss, zuerst bevor KAUDERWELSCH kompiliert werden kann, da in der Regel die interpretation von KAUDERWELSCH, hängt von der definition von value.

    (In deinem speziellen Fall, KAUDERWELSCH geschieht auf eine einfache Konstante unabhängig von value.)

    Javac muss folgern Value<T> ersten für parameter value; es gibt keine Einschränkungen in Zusammenhang, daher T=Object. Dann, lambda-Körper true zusammengestellt und anerkannt als Boolean, kompatibel mit T.

    Nachdem Sie die änderung vorgenommen, um die funktionale Schnittstelle, die lambda-parameter-Typ nicht erforderlich Inferenz; T bleibt uninfered. Neben der lambda-Körper zusammengestellt ist, und der Rückgabetyp werden angezeigt boolescher Wert, der eingestellt ist als eine untere Schranke für T.

    Einem anderen Beispiel demonstriert das Problem

    <T> void foo(T v, Function<T,T> f) { ... }

foo("", v->42);  //Error. why can't javac infer T=Object ?

    T abgeleitet werden String; der Körper des lambda-nicht an der Inferenz.

    In diesem Beispiel javac Verhalten scheint sehr vernünftig zu uns; es wahrscheinlich verhinderte ein Fehler bei der Programmierung.
    Sie wollen nicht die Inferenz zu mächtig; wenn alles, was wir schreiben kompiliert irgendwie, verlieren wir das Vertrauen der compiler auf der Suche nach Fehlern für uns.

    Gibt es andere Beispiele, wo die lambda scheint der Körper zu bieten eindeutige Einschränkungen, aber der compiler kann diese Informationen verwenden. In Java ist die lambda-parameter-Typen müssen erst beseitigt werden, bevor der Körper betrachtet werden kann. Dies ist eine bewusste Entscheidung. Im Gegensatz dazu, C# ist bereit, zu versuchen, verschiedene parameter-Typen und sehen, welche macht den code kompilieren. Java ist der Auffassung, dass zu riskant.

    In jedem Fall, wenn implizite lambda ausfällt, und das passiert ziemlich Häufig, eindeutige Typen für lambda-Parameter, in deinem Fall (Value<Boolean> value)->true

    InformationsquelleAutor ZhongYu
  3. 4

    Den einfachen Weg, dies zu beheben, ist eine Deklaration auf dem Aufruf der Methode zu foo:

    Foo.<Boolean>foo(value -> true).booleanValue();

    Edit: ich nicht finden können, die spezifische Dokumentation über, warum dies notwendig ist, ziemlich viel wie alle anderen auch. Ich vermutete, es könnte sein, weil der primitiven Typen, aber das war nicht richtig. Unabhängig davon, ist Diese syntax wird als eine Ziel-Typ. Auch Target Type in Lambda-Ausdrücke. Die Gründe entziehen sich mir zwar, ich finde keine Dokumentation darüber gibt, warum diese bestimmten Anwendungsfall erforderlich ist.

    Edit 2: fand ich diese Frage:

    Generische Typ-Inferenz nicht die Arbeit mit method-chaining?

    Sieht es aus wie es ist, weil Sie sind, die die Verkettung der Methoden hier. Nach der JSR-Kommentare verwiesen, die in der akzeptierten Antwort, es war eine bewusste weglassen von Funktionen, da der compiler nicht passieren abgeleitete generische Typ-Informationen zwischen verkettete Methodenaufrufe in beide Richtungen. Als Ergebnis, die gesamte Art ausgelöscht durch die Zeit, es kommt der Aufruf booleanValue. Hinzufügen des Ziel-type-in beseitigt dieses Verhalten, indem Sie die Einschränkung manuell, anstatt zuzulassen, dass dem compiler die Entscheidung über die beschriebenen Regeln in JLS §18, die scheint nicht zu erwähnen, das auf allen. Dies ist die einzige info, die ich gefunden habe. Wenn jemand feststellt, dass nichts besser ist, würde ich lieben, es zu sehen.

    • Ich bin mir nicht sicher, ob eine JLS-Verweis notwendig ist - ich bin nur neugierig im Allgemeinen, warum Inferenz scheint nicht hier zu arbeiten, und wenn es irgendeine änderung, die ich machen kann, um die API machen, damit es funktioniert. Im Idealfall will ich nicht verlangen, meine Benutzer müssen manuell die Typ-argument hier.
    • Es geht um die Art, wie Sie tun, Typ-Inferenz mit Ihrem Algorithmus und primitiven. Haben Sie versucht, Rückgabe Boolean.WAHR, statt einfach nur true? Ich bin mir nicht vor, eine IDE, ich kann das nicht testen im moment.
    • Zurückgeben eines Objekts wie String oder Boolean.TRUE, liefert die gleiche Art von problem.
    • Tut mir Leid um Euch Irre zu führen, nehmen Sie einen Blick auf meine edits, hoffentlich ist es die richtige info. Dieses Zeug ist schwer zu recherchieren.
    • Wenn es ein problem mit der Verkettung Methoden, ich würde nicht erwarten, dass eine änderung der Signatur zu T apply(Value value); zu haben, eine positive Wirkung, doch es tut.
    • Die syntax ist nicht als Ziel eingeben. Ziel-Eingabe wäre Boolean b = Foo.foo(value -> true); die syntax, Die Sie beschreiben (Foo.<Boolean> foo(value->true)) ist bekannt als geben Sie Zeuge.

    InformationsquelleAutor Brian
  4. 3

    Wie die anderen Antworten, ich bin auch in der Hoffnung, jemand intelligenter wird, kann aufzeigen, warum der compiler nicht in der Lage zu folgern, dass T ist Boolean.

    Einen Weg, um zu helfen out der compiler schon das richtige tun, ohne dass änderungen an Ihrer bestehenden Klassen - /interface-design, ist durch das explizite Deklaration der formalen parameter mit dem Typ in Ihrem lambda-Ausdruck. Also, in diesem Fall, indem Sie ausdrücklich erklärte, dass die Art der value parameter ist Value<Boolean>.

    void test() {
  Foo.foo((Value<Boolean> value) -> true).booleanValue();
}
    • Ändern kann ich die Klassen - /interface-design ein wenig, so lange die Foo.foo call leitet einen Rückgabetyp boolean und value im lambda abgeleitet, um Value<Boolean>. Ich will nicht zu werfen, da dies ist Teil einer öffentlichen API und erfordern eine Besetzung entsteht ein usability-problem.
    • Nur um klar zu sein, meinem Beispiel nicht durchführen jegliche casting. Es ist einfach so ausdrücklich über die formalen parameter Typ des lambda-Ausdrucks eher als Herleitung der Typ. Aber ja, ich würde auch gerne wissen, warum Sie können nicht einfach folgern, die richtige Art in diesem Fall.
    InformationsquelleAutor sstan
  5. 1

    Ich weiß nicht warum, aber Sie brauchen, um hinzuzufügen, separate return-Typ:

    public class HelloWorld{
static class Value<T> {
}

@FunctionalInterface
interface Bar<T,R> {
      R apply(Value<T> value); //Return type added
}

static class Foo {
  public static <T,R> R foo(Bar<T,R> callback) {
      return callback.apply(new Value<T>());
  }
}

void test() {
  System.out.println( Foo.foo(value -> true).booleanValue() ); //No compile error here
}
     public static void main(String []args){
         new HelloWorld().test();
     }
}

    einige smart Typ wohl erklären kann, dass.

    • Das bringt uns ein bisschen näher, aber value im lambda-Ausdruck ist geschlossen, um Value<Object> statt Value<Boolean> das wird noch Probleme verursachen in meiner realen Szenario, in dem der lambda-Ausdruck Körper enthält mehr code...
    • Nicht sicher, was du meinst. Meine Vermutung ist: Sie müssen den Typ wildcard-wenn Sie möchten, rufen Methoden auf T static class Value<T extends Boolean>, interface Bar<T extends Boolean,R>, public static <T extends Boolean,R> R foo(Bar<T,R> callback) usw...
    • Ersetzen Boolean mit Ihrer Klasse natürlich.
    • So etwas wie das scheint, wie es funktionieren könnte, außer den Rückgabetyp von lambda-könnte alles sein (gesteuert durch den Benutzer). Boolean ist nur ein Beispiel...
    InformationsquelleAutor fukanchik
  6. 1

    Problem

    Wert ableiten zu geben Value<Object> weil Sie interpretiert die lambda falsch. Denken Sie an es, wie Sie sich nennen mit dem lambda direkt die Methode anwenden. Also, was Sie tun, ist:

    Boolean apply(Value value);

    und diese richtig abgeleitet zu:

    Boolean apply(Value<Object> value);

    da haben Sie noch nicht den Typ für den Wert.

    Einfache Lösung

    Aufruf der lambda-Ausdruck in einem richtigen Weg:

    Foo.foo((Value<Boolean> value) -> true).booleanValue();

    diese wird abgeleitet zu:

    Boolean apply(Value<Boolean> value);

    (Meine) Lösung Empfohlen

    Ihre Lösung sollte man schon ein bisschen mehr klar. Wenn Sie möchten einen Rückruf, dann müssen Sie einen Typ-Wert, der zurückgegeben wird.

    Habe ich eine generic Callback-Schnittstelle eine generische Wert-Klasse und ein UsingClass, um zu zeigen, wie es zu benutzen.

    Callback-Schnittstelle

    /**
 *
 * @param <P> The parameter to call
 * @param <R> The return value you get
 */
@FunctionalInterface
public interface Callback<P, R> {

  public R call(P param);
}

    Wert Klasse

    public class Value<T> {

  private final T field;

  public Value(T field) {
    this.field = field;
  }

  public T getField() {
    return field;
  }
}

    UsingClass Klasse

    public class UsingClass<T> {

  public T foo(Callback<Value<T>, T> callback, Value<T> value) {
    return callback.call(value);
  }
}

    TestApp mit Haupt -

    public class TestApp {

  public static void main(String[] args) {
    Value<Boolean> boolVal = new Value<>(false);
    Value<String> stringVal = new Value<>("false");

    Callback<Value<Boolean>, Boolean> boolCb = (v) -> v.getField();
    Callback<Value<String>, String> stringCb = (v) -> v.getField();

    UsingClass<Boolean> usingClass = new UsingClass<>();
    boolean val = usingClass.foo(boolCb, boolVal);
    System.out.println("Boolean value: " + val);

    UsingClass<String> usingClass1 = new UsingClass<>();
    String val1 = usingClass1.foo(stringCb, stringVal);
    System.out.println("String value: " + val1);

    //this will give you a clear and understandable compiler error
    //boolean val = usingClass.foo(boolCb, stringVal);
  }
}
    • Diese Antwort scheint Weg von dem Beispiel-Szenario ein wenig, das ist eine Vereinfachung von einem realen API. Zwei Dinge: die foo Methode muss statisch sein und sollte nehmen ein einzelnes argument.
    • Die API, die Sie sprechen. Was ich getan habe, ist in JavaFX ein bisschen wie der Rückruf für eine Zelle der Tabelle mit dem Wert der Fabrik. Sie wollen, dass es statisch ist nicht das problem, denke ich. Aber nur einen Wert? Sorry, aber dann müssen Sie wahrscheinlich ein Prädikat und nicht eine Funktion oder callback.
    • Erwähnenswert ist es wieder - das wird ein Teil einer öffentlichen API, so muss es einfach zu nutzen sein. Der Benutzer muss in der Lage sein, um eine grundlegende lambda wie value -> true für die Wert wird abgeleitet werden, um Value<Boolean> und die Methode der Annahme des lambda-zurück Boolean. Alle anderen änderungen sind in Ordnung, aber diese brauchen, um im Platz zu bleiben, um die API nutzbar.
    • Hm, mir eine API sollte flexibel und Abstrakt. Was Sie getan haben in die Bar ist die Arbeit mit einem konkreten Typ, diese nicht flexibel an alle.
    • Es ist nur ein Beispiel, um das problem zu veranschaulichen. Das Ziel der real-API nicht die Flexibilität, die Einfachheit, das ist der Grund, warum wir wollen, dass foo zu akzeptieren, ein einziges argument, um diese Arbeit zu machen.
    InformationsquelleAutor aw-think
Schreibe einen Kommentar