Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Consider support for extending native generic classes and providing generic arguments

Aberta
#1,346 3 comentários 4 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
java, typescript, webpack
Domínio
build-system, mobile-dev, tooling

Direção de pesquisa

Comece pelo plugin do webpack e pelo js_parser.js descritos na issue. Rastreie como as declarações @Native e os tipos estendidos ou implementados são representados atualmente; em seguida, determine como um transformer personalizado pode preservar os argumentos genéricos para o parser. Considera-se concluído quando um código TypeScript como java.util.List<java.lang.Integer> produz um binding com esse argumento genérico em vez de Object.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
C++
Estrelas
563
Forks
144
Merge médio
10h 46min
PRs com merge (30d)
14

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de NativeScript/android

Todas as issues de NativeScript/android

Issues semelhantes

Mais issues de C++

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.