Discussion :

[adiGuba]

Les Enums sont apparus tardivement il me semble 1.5 ou 1.6 je crois.

Java 1.5
Mais ce que je veux dire c'est que ce n'est pas une transposition des enums du C/C++

Ah ?

Les Templates correspondent à une sorte de surcouche du langage. Grosso-modo c'est comme si tu faisait un gros replace sur le code avant chaque utilisation d'un type template En fait c'est le compilateur qui le fait à ta place...

Les Generics sont véritablement intégré dans le langage (la reflection permet de récupérer certaines infos relatives aux Generics), et évites la duplication du code (toutes les classes Generics sont du même types).
Le gros défaut actuel étant que le type du paramétrage est perdu à l'exécution (sauf dans certains cas spécifique) puisque chaque instance d'un type paramétré appartient au même type (une List<String> est strictement du même type qu'une List<Integer>).

Sans oublier les notions de variances qui apportent encore plus de généricité au code (j'y reviens plus bas).

et ça apporte concretement quelque chose que ce soit un objet?

A mon avis cela apporte autant que les classes en comparaison des simples structures

Le détail le plus utile c'est qu'une enum possède un toString() bien propre, si bien que ceci affichera le libellé de l'enum et non pas une valeur entière peu utile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.out.println( monEnum );

Mais on a également la possibilité de parcourir facilement les valeurs d'une enum voir de faire la conversion String -> enum :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for (MyEnum e : MyEnum.values()) {
	System.out.println(e);
}
MyEnum.valueOf("A"); // retourne MyEnum.A

Sans compter les méthodes associé à une valeur de l'enum. Un petit exemple dans l'API standard avec TimeUnit : http://javasearch.developpez.com/j2s.../TimeUnit.html

mais les premières annonces sur C# sont sorties en Janvier 1999 justement... et pas celles de Microsoft, mais de son créateur qui avait déjà C# 2.0 en tête à l'époque

Et ? Cela ne prouve pas qu'ils s'en sont inspiré...
Surtout qu'on ne peut pas dire qu'ils aient pris la même directement...(l'intégration des Generics dans Java n'a pas entrainé une cassure dans l'API).

c'est d'ailleurs pour cela qu'il a été "si facile" à C# d'introduire la contra-variance, ce qui à ma connaissance n'est pas du tout possible en C++ (ni en Java bien sûr puisqu'ils sont toujours 10 ans de retard sur tout le monde )

Hum Hum ... La variance existe déjà en Java, et ce depuis l'intégration des Generics dans Java 1.5 en 2004...

Elle prend par contre une forme quelque peu différente : elle n'a pas besoin d'être défini dans l'interface mais peu s'utiliser n'importe où par simple déclaration, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	List<? extends Object> list = new ArrayList<String>();
		
	List<? super Double> list = new ArrayList<Number>();

Pour info la variance permet d'utiliser un type Generics partiellement, en faisant des suppositions sur son type. Par exemple une List<? extends Number> peut correspondre à une liste de type étendant Number.
Comme on ne connais pas le type précis il est impossible d'ajouter des éléments dans cette liste, mais on peut très bien parcourir ses données.

Petit exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	public double sum(Iterable<? extends Number> values) {
		double result = 0.0;
		for (Number n : values) {
			result += n.doubleValue();
		}
		return result;
	}

Cette méthode accepte en paramètre n'importe quelle liste paramétré avec un type étendant Number. Sans covariance on serait obligé de dupliquer la méthode car le typeage est trop fort...




a++

[jabbounet]

Java 1.5
Mais ce que je veux dire c'est que ce n'est pas une transposition des enums du C/C++


Les Templates correspondent à une sorte de surcouche du langage. Grosso-modo c'est comme si tu faisait un gros replace sur le code avant chaque utilisation d'un type template En fait c'est le compilateur qui le fait à ta place...

Les Generics sont véritablement intégré dans le langage (la reflection permet de récupérer certaines infos relatives aux Generics), et évites la duplication du code (toutes les classes Generics sont du même types).
Le gros défaut actuel étant que le type du paramétrage est perdu à l'exécution (sauf dans certains cas spécifique) puisque chaque instance d'un type paramétré appartient au même type (une List<String> est strictement du même type qu'une List<Integer>).

Sans oublier les notions de variances qui apportent encore plus de généricité au code (j'y reviens plus bas).



A mon avis cela apporte autant que les classes en comparaison des simples structures

Le détail le plus utile c'est qu'une enum possède un toString() bien propre, si bien que ceci affichera le libellé de l'enum et non pas une valeur entière peu utile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.out.println( monEnum );

Mais on a également la possibilité de parcourir facilement les valeurs d'une enum voir de faire la conversion String -> enum :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for (MyEnum e : MyEnum.values()) {
	System.out.println(e);
}
MyEnum.valueOf("A"); // retourne MyEnum.A

Sans compter les méthodes associé à une valeur de l'enum. Un petit exemple dans l'API standard avec TimeUnit : http://javasearch.developpez.com/j2s.../TimeUnit.html

en gros tu n'as ps le choix tu es obligé de te taper un objet.
en C++ rien ne t'empêche de mettre ton enum dans une classe si tu en as besoin, ou de ne pas le faire si cela ne s'avère pas utile.

[_skip]

Oui ça amène hélas à parler de l'un des problèmes en C#.

Il est impossible de passer un List<String> à une méthode qui attend un List<Object>. Car List<String> n'est pas un héritier de List<Object>.

Ceci introduit des limitations regrettables parfois.

En revanche, passer un List<String> a une méthodes attendant un IList<String>, c'est faisable.

[adiGuba]

en gros tu n'as ps le choix tu es obligé de te taper un objet.

Et quel est le problème avec cela ???

Il est impossible de passer un List<String> à une méthode qui attend un List<Object>. Car List<String> n'est pas un héritier de List<Object>.

Cette limitation est obligatoire pour la cohérence des types, sinon cela permettrait de faire des choses comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	List<Object> list = new ArrayList<String>(); // NE COMPILE PAS
	list.add(new Date()); // OK

S'il n'y avait pas d'erreur à la première ligne, on se retrouverait avec un code qui compile sans problème mais qui ajoute une Date dans une List<String>

La variance permet justement ces conversions mais en limitant les fonctionnalités afin d'éviter les utilisations incorrectes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	List<? extends Object> list = new ArrayList<String>(); // OK
	list.add(new Date()); // NE COMPILE PAS

a++

[jabbounet]

Et quel est le problème avec cela ???

j'aime bien voir le choix sur mon typage parfois.

[adiGuba]

j'aime bien voir le choix sur mon typage parfois.

Sauf erreur en C++ l'enum est forcément un type int (ou apparenté). Non ?

a++

[_skip]

Cette limitation est obligatoire pour la cohérence des types, sinon cela permettrait de faire des choses comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	List<Object> list = new ArrayList<String>(); // NE COMPILE PAS
	list.add(new Date()); // OK

S'il n'y avait pas d'erreur à la première ligne, on se retrouverait avec un code qui compile sans problème mais qui ajoute une Date dans une List<String>

Oui c'est ce que je voulais dire, c'est regrettable lorsqu'on a besoin d'utiliser une collection en lecture seule dont le contenu serait acceptable.

On ne peut pas passer une List<Chat> à une méthode qui attend une List<Animal> en C#. Alors qu'en java on peut feinter avec la contrainte de type que tu as cité.

C'est un très bon compromis... En revanche, corrige moi si je me trompe mais puisque l'information du typage est perdue à la compilation, aucune optimisation n'est faite sur les contrôles de type lors de l'ajout et de la récupération d'items dans les collections?

[jabbounet]

Sauf erreur en C++ l'enum est forcément un type int (ou apparenté). Non ?

Oui mais ce n'est pas un objet, si je veux le gérer par objet je peux le faire en implémentant une classe par dessus mais je ne suis pas obligé. j'ai le choix quoi

[spidermario]

Sauf erreur en C++ l'enum est forcément un type int (ou apparenté). Non ?

a++

Cf. ce qu'il a dit plus haut :

en C++ rien ne t'empêche de mettre ton enum dans une classe si tu en as besoin, ou de ne pas le faire si cela ne s'avère pas utile.

Edit : grillé

[GanYoshi]

Oui mais ce n'est pas un objet, si je veux le gérer par objet je peux le faire en implémentant une classe par dessus mais je ne suis pas obligé. j'ai le choix quoi

J'imagine facilement les cas dans lesquels tu aurait besoin d'implémenter une classe par dessus, mais pas les cas dans lesquels le fait que ça soit un objet te pose un problème.

Peut-tu m'éclairer ?

[jabbounet]

J'imagine facilement les cas dans lesquels tu aurait besoin d'implémenter une classe par dessus, mais pas les cas dans lesquels le fait que ça soit un objet te pose un problème.

Peut-tu m'éclairer ?

Dans a peu pres 90 % des cas je n'ai pas besoin de plus que ce qui est fournit par l'enum C++ un int avec un certain nombre de valeur.

En fait il est plutôt rare que j'ai besoin de toutes l'artillerie objet autour de l'enum notament de faire un toString() dessus.

mais les programmes sur lesquel je travaille sont plutôt proche du matériel en général.

[GanYoshi]

Dans a peu pres 90 % des cas je n'ai pas besoin de plus que ce qui est fournit par l'enum C++ un int avec un certain nombre de valeur.

En fait il est plutôt rare que j'ai besoin de toutes l'artillerie objet autour de l'enum notament de faire un toString() dessus.

mais les programmes sur lesquel je travaille sont plutôt proche du matériel en général.

J'ai bien compris que tu n'avais pas souvent besoin que enum soit un objet, je n'ai cependant toujours pas compris quand le fait que l'enum soit un objet te pose problème .

[koala01]

J'ai bien compris que tu n'avais pas souvent besoin que enum soit un objet, je n'ai cependant toujours pas compris quand le fait que l'enum soit un objet te pose problème .

En C++ ce pourrait en être un car l'habitude favorisée consiste à transmettre les primitifs et équivalents par valeur et les objets par référence...

Nous passons donc généralement une enum par valeur (vu qu'elle est équivalente à un int )

Si l'enum était un objet, il faudrait la passer... par référence

Mais bon, comme les enum's ne sont pas des objet en C++ et que, de toutes manières java fonctionne d'office par références, voici bien un post qui ne sert à rien

[gorgonite]

Et ? Cela ne prouve pas qu'ils s'en sont inspiré...
Surtout qu'on ne peut pas dire qu'ils aient pris la même directement...(l'intégration des Generics dans Java n'a pas entrainé une cassure dans l'API).

c'est une contrainte de Java de ne jamais "rompre" avec le passé, même si en fait cela passe pour une réécriture à la volée du bytecode au moment de l'exécution (ou une grosse lenteur du à la petite surcharge nécessaire)

je disais juste que cela relativise quelque peu le fait qu'ils aient forcemment pensé d'eux mêmes à l'introduire dans le langage... après chacun sa manière de faire avec les contraintes maison

nb : cela ne signifie pas non plus qu'ils n'y aient pas pensé d'eux mêmes... c'est juste une zone d'ombre qu'on ne peut à notre niveau pas éclaircir

Hum Hum ... La variance existe déjà en Java, et ce depuis l'intégration des Generics dans Java 1.5 en 2004...

je parlais de contra-variance et non de variance. bien sûr, tu as forcemment la variance puisque les generics sont réellement intégrés au langage

Il est impossible de passer un List<String> à une méthode qui attend un List<Object>. Car List<String> n'est pas un héritier de List<Object>.

Ceci introduit des limitations regrettables parfois.

En revanche, passer un List<String> a une méthodes attendant un IList<String>, c'est faisable.

cf contra-variance dans le lien que j'ai donné...

C'est un très bon compromis... En revanche, corrige moi si je me trompe mais puisque l'information du typage est perdue à la compilation, aucune optimisation n'est faite sur les contrôles de type lors de l'ajout et de la récupération d'items dans les collections?

faux... si tu perdais toute forme de typage à la compilation, tu n'aurais plus possibilité de faire de l'introspection réelle (ce qui est le cas en C++, et qui pose parfois des "problèmes" sur des surcharges/non surcharges avec différents types arguments)

[_skip]

faux... si tu perdais toute forme de typage à la compilation, tu n'aurais plus possibilité de faire de l'introspection réelle (ce qui est le cas en C++, et qui pose parfois des "problèmes" sur des surcharges/non surcharges avec différents types arguments)

On parle pas de la même chose je pense...
Je parlais du type en paramètre dans le cas d'une classe générique, en l'occurence du String dans ArrayList<String>.

[gorgonite]

On parle pas de la même chose je pense...
Je parlais du type en paramètre dans le cas d'une classe générique, en l'occurence du String dans ArrayList<String>.

effectivement, j'avais trop généralisé


je crois qu'effectivement par des soucis de compatibilité avec les versions précédentes de java, ce genre d'info est "perdue" à la fin de la compilation (ArrayList<T> est vue en interne comme ArrayList, sinon on ne serait plus compatible avec les api < 1.5)

http://tutorials.jenkov.com/java-ref.../generics.html


mais je crois que cela peut en fait être retrouvé dynamiquement, si je ne confonds pas... je ne fais pas du Java tous les jours

[jabbounet]

J'ai bien compris que tu n'avais pas souvent besoin que enum soit un objet, je n'ai cependant toujours pas compris quand le fait que l'enum soit un objet te pose problème

je n'ai pas dit que cela me posais un problème mais que j'aimais avoir le choix ce n'est pas tout a fait pareil

[adiGuba]

c'est une contrainte de Java de ne jamais "rompre" avec le passé,

En effet

même si en fait cela passe pour une réécriture à la volée du bytecode au moment de l'exécution (ou une grosse lenteur du à la petite surcharge nécessaire)

Les types Generics correspondent en fait un des types génériques où les casts sont implicite et dont le typage est vérifié à la compilation.

je disais juste que cela relativise quelque peu le fait qu'ils aient forcemment pensé d'eux mêmes à l'introduire dans le langage... après chacun sa manière de faire avec les contraintes maison

Et je disais juste que contrairement à ce que beaucoup pense, les Generics de Java 5.0 ne sont pas une réponse aux Generics de C# 2.0

D'autant que le début du processus de la JSR ne veut pas dire qu'on n'en parlais pas plus tôt. A titre d'exemple ca fait pas mal de temps qu'on parle de Closures en Java, mais il n'existe encore aucune JSR...

je parlais de contra-variance et non de variance. bien sûr, tu as forcemment la variance puisque les generics sont réellement intégrés au langage

Oui par "variance" je regroupais les notion de covariance et de contra-variance. Les wildcards permettent d'utiliser la covariance et la contra-variance sur les typeage Generics

faux... si tu perdais toute forme de typage à la compilation, tu n'aurais plus possibilité de faire de l'introspection réelle (ce qui est le cas en C++, et qui pose parfois des "problèmes" sur des surcharges/non surcharges avec différents types arguments)

Tu ne le perd pas à la compilation, mais tu perds les informations propres à une instance.

par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class MaClasse<T extends Number> {
    ...
}

Par reflection tu peux récupérer les infos propres à la classe (le T extends Number), mais tu ne peux pas récupérer des infos propre à une instance :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Object a = new MaClasse<Double>();

Tu n'a aucun moyen de retrouver dynamiquement le type "Double"...
(bien sûr il y a d'autre moyen de faire cela)

je crois qu'effectivement par des soucis de compatibilité avec les versions précédentes de java, ce genre d'info est "perdue" à la fin de la compilation (ArrayList<T> est vue en interne comme ArrayList, sinon on ne serait plus compatible avec les api < 1.5)

Non ArrayList<T> est bien vue comme ArrayList<T>...
En fait c'est ArrayList<String>, ArrayList<Integer>, etc. qui sont vue comme des ArrayList<T>.

en clair une instance n'est pas lié à son type paramétré...

On parle de "reified Generics" pour Java 7 qui permettrait de récupérer le typeage pris d'une instance, mais rien n'est sûr pour le moment...


a++

[gorgonite]

Oui par "variance" je regroupais les notion de covariance et de contra-variance. Les wildcards permettent d'utiliser la covariance et la contra-variance sur les typeage Generics

ça date de quelle version ?

Tu ne le perd pas à la compilation, mais tu perds les informations propres à une instance.

je parlais de C++...

Non ArrayList<T> est bien vue comme ArrayList<T>...
En fait c'est ArrayList<String>, ArrayList<Integer>, etc. qui sont vue comme des ArrayList<T>.

en clair une instance n'est pas lié à son type paramétré...

au temps pour moi... mais je croyais justement que pour "rendre" compatible ce genre de code sur du 1.4.2 on utilisait des réécritures bizarres de bytecode, et des vérifications juste avant

On parle de "reified Generics" pour Java 7 qui permettrait de récupérer le typeage pris d'une instance, mais rien n'est sûr pour le moment...

ça redonnerait un peu plus de sens à l'introspection... théoriquement au moins

[djisse]

Bon bah moi je vais revenir au sujet principale et voici mon avis:
Je préfére le java, car il est portable, contrairement au C++,beaucoup moins complexe que le C++, et puissant de part ses api et package(JDBC,JEE....).
De plus certaine personne lui reproche d'être lent, mais j'ai lu dans un bouquin que cela dependait du code, et de la facon dont on code!
Ensuite le fait qu'il soit complétement Orienté Objet en fait un atout pour les entreprises, qui y voient une organisation plus facile. Pour moi le Java m'a appris a reflechir, car avant je codais et codé(en C), mais maintenant je prend le temps de me poser et modeliser mes applications... De cette facon j'evite les bugs, et je vais plus rapidement!