Bonjour,

j'aimerais savoir en quoi seraient utiles les classe wrappers?
Quelle est l'interêt de pouvoir utiliser nos primitifs comme des objets?

Etant donné que je débute, je n'arrive pas à voir plus loing...

Merci!!

Pouvoir les utiliser comme des objets, tout simplement.
Ca implique pouvoir les définir à null et ne pas avoir à les gérer différemment du reste, entre autres.

Maintenant que Spacefox a bien répondu à la question, j'aimerais bien la poser à l'envers...

Le tout-objet me semble plus facile à gérer, moins ambigue, mais bon y'a le problème éventuel des perfs d'une part, l'absence de surcharge d'opérateur d'autre part, et une ambiguïté merdique à lever pour certaines méthodes (List.get au plus grand des hasards).
Les pros, vous avez une position sur "dégager les types primitifs" comme ça se fait en Smalltalk ou Groovy (pour prendre un truc plus proche de Java)

Les perfs, à moins de tenter du calcul haute performances, c'est clairement pas là que tu les perds.
La surcharge d'opérateurs n'existe de toutes manières pas en Java. Par contre, depuis Java 5 tu peux quand même faire des calculs avec des types encapsulés dans des classes Wrapper, merci à l'autoboxing.

Je ne comprends pas ton problème d'ambiguité pour la méthode List.get, tu peux préciser ? Paramètres-tu bien tes listes ?

Non mais les problèmes éventuels c'est SI tout est objet. Côté performances, c'est le taff de la JVM, on est d'accord.

Côté surcharge d'opérateurs, si tout est objet tu "perdrais" les opérateurs classiques sans pouvoir en avoir de nouveaux.

Et pour l'ambiguité, imaginons (dans un contexte où les types primitifs n'existent pas hein) une List<Integer> comment tu différencies l'appel à get(Object) et get(indice) ?

pour la surcharge d'opérateur il suffirait de faire des conversion implicite que dirait que a + b se réécrit en a.operator+(b). Pareil pour tout les autres opérateur. Ce mécanisme se rapproche du C++. Ici, seulement un pré-compilateur entrerait en jeu, on ne change rien au compilateur lui-même.

pour le get, il suffirait de prendre l'objet le plus spécialisé (le plus bas dans l'arbre d'héritage). ça ne résoud pas le problème de deux objets à la même profondeur.

Hedi

Merci pour vos reponses!!!

Citation : Javier

Non mais les problèmes éventuels c'est SI tout est objet. Côté performances, c'est le taff de la JVM, on est d'accord.

Là je ne vois pas où tu veux en venir.

Citation : Javier

Côté surcharge d'opérateurs, si tout est objet tu "perdrais" les opérateurs classiques sans pouvoir en avoir de nouveaux.

Pas forcément. Par exemple, tu as des spécificités sur String, qui est un objet et qui pourtant est utilisable avec des opérateurs (genre + pour concaténer). On peut très bien imaginer la même chose pour les nombres sans avoir à introduire la surcharge d'opérateurs.

Citation : Javier

Et pour l'ambiguité, imaginons (dans un contexte où les types primitifs n'existent pas hein) une List<Integer> comment tu différencies l'appel à get(Object) et get(indice) ?

Tout simplement parce que get(Object) n'a aucun sens sur une liste, et que get(indice) n'a aucun sens sur une table de hashage.
Maintenant, si tout est objet, tout n'est pas forcément du type Object. Typiquement, ta méthode List n'aurait pas une méthode get(Object) mais une méthode get(Integer) (auquel tu pourrais passer un objet qui étend Integer s'il était permis d'étendre cette classe).

Remplace get par remove dans mon exemple, pardon.

Pour les opérateurs c'est notamment ce que fait Groovy ( et peut-êtrre Scala je ne sais pas), par contre si en Java Sun l'a fait pour les chaînes, ils ne semblent pas trop enclin à le faire pour d'autres types (BigInteger, BigDecimal, ...) pourquoi ? Aucune idée, mais ça n'a pas été intégré à Java 7 et pas prévu pour Java 8.

Pour les méthode ambigues, je suppose qu'ils auraient nommé leur "remove" de manière un peu plus intelligente (cette méthode peut provoquer des surprises quand on a l'habitude de l'autoboxing, par exemple).

Pour les opérateurs, ils ont déjà mis en place l'autoboxing, c'est pas mal.
Je pense que BigInteger et BigDecimal n'y auront pas droit parce qu'elles ne fonctionnent pas comme les nombres normaux. De plus, elles sont beaucoup plus lentes (je n'ai plus les chiffres en tête mais je crois que c'est quelque chose comme un facteur 1000, un truc gigantesque en tous cas) que les nombres même wrappés.