jextract/jni: Expose Swift protocol requirement defaults to Java callbacks
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- backend-api-design
Direzione di ricerca
Start by reading #562 and #891, which describe related extension-member and compilation behavior, then inspect the JNI callback generation entry points in the repository. Determine how an unconditional Swift protocol extension implementation can remain the implementation while calls to other requirements dispatch to Java overrides; done means Java callbacks can inherit that default and the example works.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
JNI callback interfaces currently leave protocol requirements abstract even when Swift supplies an unconditional implementation in an extension. Java implementors must repeat that implementation instead of inheriting the Swift behavior.
Example
public protocol Greeter {
func name() -> String
func greeting() -> String
}
extension Greeter {
public func greeting() -> String { "Hello, \(name())" }
}
With Java callbacks enabled, it would be useful for a Java implementation to provide only name() and inherit the Swift implementation of greeting():
Greeter greeter = () -> "World";
String message = greeter.greeting(); // "Hello, World"
The Swift body should remain the implementation, and its calls to other requirements should dispatch to the Java receiver, including any Java overrides.
This is related to #562, which discusses exposing extension members as Java default methods, and #891, which reports a compilation error when a protocol requirement has a default implementation.
Reference workaround implementation: https://github.com/qoncept/swift-java/pull/11
- Lingua principale
- Swift
- Stelle
- 1.3k
- Fork
- 127
- Merge medio
- 2g 14h
- PR unite (30g)
- 5
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di swiftlang/swift-java
-
wrap-java: Optional convenience methods can fail to compile when a parameter shadows the method nameAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
swiftlang/swift-java#945 ·
I maintainer di solito rispondono entro 1 giorno
-
android
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
swiftlang/swift-java#663 · 4 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 56/100
swiftlang/swift-java#949 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 54/100
swiftlang/swift-java#947 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 53/100
swiftlang/swift-java#946 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di swiftlang/swift-java
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
VictorKildahl/cra#192 ·
I maintainer di solito rispondono entro 1 giorno
-
area:docs phase:release priority:p0 type:test
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
[Type] Bug Accessibility Notifications
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
wordpress-mobile/WordPress-iOS#26340 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno