NativeScript / NativeScript/android

Consider support for extending native generic classes and providing generic arguments

Aperta
#1,346 3 commenti 4 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Lingua principale
C++
Stelle
563
Fork
144
Merge medio
10h 46m
PR unite (30g)
14

Descrizione

Currently, there is no way to implement for example java.util.List<T> and provide information what would be the type T. When extending such class/interface from TypeScript the following way:

@Interfaces([java.util.List])
class JSList implements java.util.List {
}

the static binding generator prior 5.3.1 would generate a proxy class with a similar signature:
public class JSList implements java.util.List
The introduced changes of the SBG in 5.3.1 generate public class JSList implements java.util.List<Object> having resolved the generic parameter T using its erasure (in this case java.lang.Object) as if it's a raw class inheritance.

With the changes of the SBG in 5.3.1, there is a way to feed it information about what would be the generic parameters when extending, however this would require some changes in the syntax of extending/implementing native classes:

@Native
class JSList implements java.util.List<java.lang.Integer>{
}

The above shown syntax would be possible with some changes in the webpack plugin and the js_parser.js in the SBG.
In order to collect information about the generic arguments provided in the TS code there should be a custom transformer plugged into the webpack pipeline whose goal would be to lookup every TS node with a @Native decorator and preserve its extended class and implemented interfaces information somewhere. This could be stored by modifying the AST and creating internal decorators only for storage. Further, when the js_parser.js parses the JS code, it can look for the internal decorators and retrieve the information about the generics storing them for the SBG.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia con il plugin webpack e js_parser.js descritti nell’issue. Traccia il modo in cui le dichiarazioni @Native e i tipi estesi o implementati sono rappresentati attualmente, quindi determina come un trasformatore personalizzato possa preservare gli argomenti generici per il parser. Il lavoro è completato quando un codice TypeScript come java.util.List<java.lang.Integer> produce un binding con quell’argomento generico anziché Object.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
java, typescript, webpack
Ambito
build-system, mobile-dev, tooling
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.