Question sur les generics

Bonjour,

En lisant les articles, j'ai compris que les Generics n'étaient pas un des gros points forts dans Java ( + typage renforcé), et critiquer par certains ( - perte de l'information au runtime).

Je lisais que les ingénieurs ayant participer au développement des Generics ont cherché à être retro-compatible avec les versions précédente à 1.5. Mais je n'arrive pas à comprendre en quoi cela aurait pu casser le code précédent ? Comme les membres synthetic, pourquoi l'information ne peut être garder ?

Salut,

Citation:

---

Envoyé par miya

En lisant les articles, j'ai compris que les Generics n'étaient pas un des gros points forts dans Java ( + typage renforcé), et critiquer par certains ( - perte de l'information au runtime).

---

Perso je ne suis pas du tout d'accord là dessus...

Les Generics ont certes des désavantages, mais également d'autres avantages non négligeable (rétrocompatibilité, meilleure covariance/contravariance, pas de duplication des types).

Citation:

---

Envoyé par miya

Je lisais que les ingénieurs ayant participer au développement des Generics ont cherché à être retro-compatible avec les versions précédente à 1.5. Mais je n'arrive pas à comprendre en quoi cela aurait pu casser le code précédent ? Comme les membres synthetic, pourquoi l'information ne peut être garder ?

---

Dans la majorité des langages, les Generics/Templates sont basé sur des templates justement. C'est à dire que grosso-modo le code sert de modèle et le compilateur fait des remplacement du type "T" par le type utilisé. En C# c'est un peu la même chose sauf que ceci est fait à l'exécution.

Mais du coup cela produit des classes différentes. Ainsi dans ce cas List<String> n'est pas le même type que List<Date>, et on ne peut pas caster cela dans un List ou un List<?>.

Si Java avait opté pour cette solution là, il aurait fallu abandonner l'API de Collections pour créer une nouvelle API totalement incompatible.
C'est d'ailleurs ce qui a été fait dans C# avec les namespaces System.Collections et System.Collections.Generic...



Reste la solution d'ajouter un membre synthetic comme tu le proposes, mais cela augmenterait l'utilisation mémoire de chaque instance pour le stocker, ce qui n'est pas forcément toujours souhaitable (le surcoût pourrait être important pour les "petits" types), alors que ce n'est pas forcément nécessaire...
:arrow: autant laissé cela à la charge du dev s'il en a vraiment besoin.


a++

Juste pour compléter mon propos :

• Un des gros avantages du type-erasure, c'est d'être bien plus simple à mettre en place, surtout dans un langage dynamique faiblement typé !
  :arrow: On peut toujours utiliser les versions non-Generics tout en utilisant des méthodes les utilisants.
  
  
• Un des gros désavantages, c'est l’incompatibilité avec les types primitifs, ce qui oblige à réécrire des classes spécifiquement.

D'ailleurs sur ce dernier point le projet Valhalla, qui devrait apporter les types-valeurs dans Java, pourrait changer la donne.
En effet l'ajout de type-value impliquerait un nombre infini de type incompatible avec les Generics...
Pour éviter cela ils envisagent le support des types primitifs/values dans les Generics via une sorte de "reification" pour ces types, couplé à la notion de "Specialization" qui permet de modifier le type (tout ou partie) selon son type paramétré.
Ex :

• List<int> pourrait proposer directement une méthode sum(), qui ne serait pas présente avec d'autres types comme List<String> ou List<char>...
• ArrayList<boolean> pourrait être basé sur un BitSet au lieu d'un boolean[] (ce dernier étant plus couteux en mémoire).
• Certaines méthodes potentiellement "ambigu" (comme remove(T) et remove(int)) seraient exclusive au références (pour la rétrocompatibilité), et serait "remplacées" par des versions mieux nommées (comme removeByValue(T) et removeByIndex(int) par exemple).
• ...

a++