|
Generics v1.2
|
L'implémentation 1.2 de la specif sur les generics est sortie
(si ca interresse qqun :)
<http://developer.java.sun.com/developer/earlyAccess/adding_generics/>
Rappelons pour ceux-ce qui n'ont pas suivi, les generics c'est
approximativement les templates du C++ en Java.
pro:
- un seule code pour tous les instantiations.
- typage des paramètres des generics.
- verification du generic à la compile !!
- ajout de la covariance sur les types de retour.
- typage des Collections :)
cons:
- pas de type primitif.
- pas d'augmentation de vitesse dans l'immediat,
il faudra réécire les JITs pour cela.
- pas de polymorphisme sur les valeurs typées par
un paramètre des generics.
( à mon avis le plus gros problème).
voila.
Remi
 |
|
At 11:41 AM 3/21/2002 +0100, you wrote:
>L'implémentation 1.2 de la specif sur les generics est sortie
>(si ca interresse qqun :)
>
><http://developer.java.sun.com/developer/earlyAccess/adding_generics/>
>
>Rappelons pour ceux-ce qui n'ont pas suivi, les generics c'est
>approximativement les templates du C++ en Java.
>
>pro:
> - un seule code pour tous les instantiations.
> - typage des paramètres des generics.
> - verification du generic à la compile !!
> - ajout de la covariance sur les types de retour.
> - typage des Collections :)
corollaire mon cher Remi, enfin plus de casts a gogo!!!!
Jerome
|
|
Bonjour la liste
Je ne comprend pas très bien l'intérêt de ce système, hormis peut-être le
gain de temps dans la résolution des références lors du polymorphisme, car
Java fournit déjà un container générique qui est Object.
Mais je pense qu'il y a des bonnes raisons qui m'échappent...
Jerome Moliere wrote:
> At 11:41 AM 3/21/2002 +0100, you wrote:
>
>> L'implémentation 1.2 de la specif sur les generics est sortie
>> (si ca interresse qqun :)
>>
>> <http://developer.java.sun.com/developer/earlyAccess/adding_generics/>
>>
>> Rappelons pour ceux-ce qui n'ont pas suivi, les generics c'est
>> approximativement les templates du C++ en Java.
>>
>> pro:
>> - un seule code pour tous les instantiations.
>> - typage des paramètres des generics.
>> - verification du generic à la compile !!
>> - ajout de la covariance sur les types de retour.
>> - typage des Collections :)
>
> corollaire mon cher Remi, enfin plus de casts a gogo!!!!
>
> Jerome
>
|
|
----- Original Message -----
From: "Pierre-François Lemosquet" <pf.lemosquet@wokup.com>
To: <java@u-strasbg.fr>
Sent: Thursday, March 21, 2002 6:20 PM
Subject: Re: Generics v1.2
> Bonjour la liste
>
> Je ne comprend pas très bien l'intérêt de ce système, hormis peut-être
> le gain de temps dans la résolution des références lors du
> polymorphisme, car Java fournit déjà un container générique qui est
> Object.
>
> Mais je pense qu'il y a des bonnes raisons qui m'échappent...
Admettons que tu veuille une liste de String tu fait :
List strings = new ArrayList();
strings.add("regarde bien ça :");
strings.add(new Integer(3));
strings.add("y a pas un truc qui cloche ?");
Voilà en gros.
-- Nicolas Repiquet
|
|
Pierre-François Lemosquet wrote:
> Bonjour la liste
>
> Je ne comprend pas très bien l'intérêt de ce système, hormis peut-être
> le gain de temps dans la résolution des références lors du
> polymorphisme, car Java fournit déjà un container générique qui est
> Object.
>
> Mais je pense qu'il y a des bonnes raisons qui m'échappent...
la verification est faite lors de la compile et pas a l'execution.
Remi
|
|
----- Original Message -----
From: "Remi Forax" <forax@univ-mlv.fr>
To: <java@u-strasbg.fr>
Sent: Thursday, March 21, 2002 11:41 AM
Subject: Generics v1.2
> L'implémentation 1.2 de la specif sur les generics est sortie
> (si ca interresse qqun :)
>
> <http://developer.java.sun.com/developer/earlyAccess/adding_generics/>
>
> Rappelons pour ceux-ce qui n'ont pas suivi, les generics c'est
> approximativement les templates du C++ en Java.
Héhé ca va bien dans la lignée de tes articles sur les templates.
> pro:
> - un seule code pour tous les instantiations.
> - typage des paramètres des generics.
> - verification du generic à la compile !!
> - ajout de la covariance sur les types de retour.
> - typage des Collections :)
>
> cons:
> - pas de type primitif.
> - pas d'augmentation de vitesse dans l'immediat,
> il faudra réécire les JITs pour cela.
> - pas de polymorphisme sur les valeurs typées par
> un paramètre des generics.
> ( à mon avis le plus gros problème).
>
> voila.
Tu veut dire qu'un truc comme ça ne passe pas :
ArrayList<Number> numbers = new ArrayList<Number>();
numbers.add(new Integer(3)); // ?
Merci pour l'info en tout cas.
> Remi
-- Nicolas Repiquet
|
|
> From: Remi Forax [mailto:forax@univ-mlv.fr]
> la verification est faite lors de la compile et pas a l'execution.
Je suis un fan absolu des templates en C++ mais pour Java, je suis de
moins en moins convaincu de leur importance. Quelques raisons :
1) L'implementation actuelle ne touche pas au bytecode. C'est
parfaitement comprehensible, pour garantir la compatibilite anterieure,
mais en gros, cela signifie que le seul gain est a la compilation. Le
cout a l'execution reste le meme: c'est celui d'un cast, meme si ce cast
n'est plus present dans le source (ce qui est trompeur, au moins un cast
dans un source Java est une sonnette d'alarme).
2) De mon experience, les erreurs au runtime liees a une erreur de type
sont rares.
3) La syntaxe va se compliquer enormement, meme si ca semble acceptable
maintenant (la syntaxe des templates C++ etait tres simple il y a dix
ans).
4) Un des principaux problemes avec les templates C++ (code bloat)
n'est pas resolu par cette proposition. Il n'y a aucun partage de code.
Bref, si je devais voter, je serais contre l'incorporation des
generiques dans Java (apparemment, je ne suis pas le seul).
--
Cédric
|
|
> 1) L'implémentation actuelle ne touche pas au bytecode. C'est
> parfaitement compréhensible, pour garantir la compatibilité antérieure,
> mais en gros, cela signifie que le seul gain est a la compilation.
Le gain est à l'écriture. Il n'est plus nécessaire d'écrire la classe
VecteurDeMaClasse (et de redéfinir les get et les set pour inclure les
casts) mais simplement Vector<MaClasse>
> 2) De mon expérience, les erreurs au runtime liées a une erreur de type
> sont rares.
Je l'ai déjà rencontré. Erreurs détectés avant livraison, mais cela est un
peu dommage. C'est le reproche que je fais au langage peu type (ASP, PHP,
....). Les erreurs se détecte à l'exécution et non à la compilation. Je
suis peut être de la veille école, mais je prône les langage hyper-typé et
les "Generics" vont dans ce sens.
Je trouve que ça "simplifie" la lecture.
Je préfère :
public void add(Vector<String> values)
à :
public void add(Vector values)
Au moins on sait de quoi doit être composé le vecteur, sans éplucher le
Javadoc.
> 3) La syntaxe va se compliquer énormément, même si ça semble
acceptable...
Je pense que l'ajout sera peu douloureux (a part quand on commence Java).
Mais c'est aussi le cas en C++. On n'utilise pas les templates tout de
suite.
> 4) Un des principaux problèmes avec les templates C++ (code bloat)
> n'est pas résolu par cette proposition.
Que veux tu dire ?
> Bref, si je devais voter, je serais contre l'incorporation des
> génériques dans Java (apparemment, je ne suis pas le seul).
J'attend cette fonctionnalité depuis si longtemps que je vote oui des deux
mains :-)
--------------------------------------------------------------------
Erik Mazoyer, Chef de projet
HyperOffice
6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex
Tél. 01 41 96 96 76
Fax 01 41 96 96 77
Mél erik.mazoyer@hyperoffice.fr
----- Original Message -----
From: "Cedric Beust" <cedric@beust.com>
To: <java@u-strasbg.fr>
Sent: Thursday, March 21, 2002 8:30 PM
Subject: RE: Generics v1.2
> > From: Remi Forax [mailto:forax@univ-mlv.fr]
>
> > la verification est faite lors de la compile et pas a l'execution.
>
> Je suis un fan absolu des templates en C++ mais pour Java, je suis de
> moins en moins convaincu de leur importance. Quelques raisons :
>
> 1) L'implementation actuelle ne touche pas au bytecode. C'est
> parfaitement comprehensible, pour garantir la compatibilite anterieure,
> mais en gros, cela signifie que le seul gain est a la compilation. Le
> cout a l'execution reste le meme: c'est celui d'un cast, meme si ce
> cast n'est plus present dans le source (ce qui est trompeur, au moins un
> cast dans un source Java est une sonnette d'alarme).
>
> 2) De mon experience, les erreurs au runtime liees a une erreur de type
> sont rares.
>
> 3) La syntaxe va se compliquer enormement, meme si ca semble acceptable
> maintenant (la syntaxe des templates C++ etait tres simple il y a dix
> ans).
>
> 4) Un des principaux problemes avec les templates C++ (code bloat)
> n'est pas resolu par cette proposition. Il n'y a aucun partage de code.
>
> Bref, si je devais voter, je serais contre l'incorporation des
> generiques dans Java (apparemment, je ne suis pas le seul).
>
> --
> Cédric
>
|
|
> > 4) Un des principaux problèmes avec les templates C++ (code bloat)
> > n'est pas résolu par cette proposition.
>
> Que veux tu dire ?
Si je ne comprends pas mal, le code va être généré 3 fois pour
supporter 3 types différents. Non?
Yoz (Yagiz)
http://www.erkans.com
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
|
|
Ce qui est dommage, c'est que de nouveaux bytecodes pourraient être
utilisés. De toute manière, les minor et major versions des .class
changent constamment. Donc une VM plus ancienne a de fortes chances de ne
pas pouvoir faire tourner des .class produits par un compilateur plus
récent. Alors pourquoi ne pas aller jusqu'au bout?
Olivier
"Cedric Beust"
<cedric@beust.co To:
<java@u-strasbg.fr>
m> cc:
Subject: RE: Generics v1.2
21/03/2002 02:30
PM Please
respond to java
1) L'implementation actuelle ne touche pas au bytecode. C'est
parfaitement comprehensible, pour garantir la compatibilite anterieure,
mais en gros, cela signifie que le seul gain est a la compilation. Le
cout a l'execution reste le meme: c'est celui d'un cast, meme si ce cast
n'est plus present dans le source (ce qui est trompeur, au moins un cast
dans un source Java est une sonnette d'alarme).
|
|
> From: Yagiz Erkan [mailto:yagiz@erkans.com]
> > > 4) Un des principaux problèmes avec les templates C++ (code
bloat)
> > > n'est pas résolu par cette proposition.
> >
> > Que veux tu dire ?
>
> Si je ne comprends pas mal, le code va être généré 3 fois
> pour supporter 3 types différents. Non?
Exactement. C'est un probleme tres complexe, et pour l'avoir vecu "en
direct" pendant que je participais au comite C++, je peux vous dire que
ces considerations se revelents toujours etre infiniment plus complexes
qu'elles n'ont l'air initialement.
--
Cédric
|
|
----- Original Message -----
From: "Yagiz Erkan" <yagiz@erkans.com>
To: <java@u-strasbg.fr>
Sent: Thursday, March 21, 2002 10:22 PM
Subject: Re: Generics v1.2
> Si je ne comprends pas mal, le code va être généré 3 fois pour
> supporter 3 types différents. Non?
Je pense que cette impression te viens du fait qu'en C++ les
implémentations des templates ressemblent plus à des macros perfectionnées
qu'a du vrai code, et qu'effectivement les code est généré autant de fois
qu'il y a de types utilisés avec le template.
Pour la version java, il me semble que le code n'est généré qu'une fois,
et que le reste n'est qu'une bonne vérification à la compile, et des casts
au runtime ( en fait, c'est possible grace au fait que toutes les classes
java hérite d'Object, je me rappel plus le nom du concept disons "comme
smalltalk" =). Personellement je vois franchement l'interet des
templates. Ca sert à rien de faire un language fortement typé si tout ce
qui sort des collection est verifié au runtime, sans parler des problême
de compréhension. Par exemple si une methode renvoi un Iterator tu fait
quoi ? Moi je vais voir la doc pour savoir que me renvoi le next(), et ça
ça montre bien qu'il y a un problême. Alors que maintenant, les
Iterator<String> y a plus de question ( et plus de cast au passage ).
> Yoz (Yagiz)
> http://www.erkans.com
-- Nicolas Repiquet
|
|
Erik Mazoyer wrote:
...
3) La syntaxe va se compliquer énormément, même si ça semble
acceptable...
Je pense que l'ajout sera peu douloureux (a part quand on commence Java).
Mais c'est aussi le cas en C++. On n'utilise pas les templates tout de
suite.
pour illustrer le propos de Cédric sur la complexification de la syntaxe, voici un exemple tirer de la spec (page 4) :
class Client {
Seq<String> strs =
new Seq<String>("a", new Seq<String>("b", new Seq<String>()));
Seq<Number> nums =
new Seq<Number>(new Integer(1),
new Seq<Number>(new Double(1.5),
new Seq<Number>()));
Seq<String>.Zipper<Number> zipper = strs.new Zipper<Number>();
Seq<Pair<String,Number>> combined = zipper.zip(nums);
}
Bruno
|
|
Nicolas Repiquet wrote:
> ----- Original Message -----
> From: "Remi Forax" <forax@univ-mlv.fr>
> To: <java@u-strasbg.fr>
> Sent: Thursday, March 21, 2002 11:41 AM
> Subject: Generics v1.2
>
...
>
>
> Tu veut dire qu'un truc comme ça ne passe pas :
>
> ArrayList<Number> numbers = new ArrayList<Number>();
> numbers.add(new Integer(3)); // ?
non, ca ca marche.
par contre :
class Test {
void f(Object o) { ... }
void f(String s) { ... }
<T> m(T t) {
f(t);
}
}
appel toujours f(Object). :(
Remi
|
|
Yagiz Erkan wrote:
>>>4) Un des principaux problèmes avec les templates C++ (code bloat)
>>>n'est pas résolu par cette proposition.
>>
>>Que veux tu dire ?
>
>
> Si je ne comprends pas mal, le code va être généré 3 fois pour
> supporter 3 types différents. Non?
non, un seul code ecrit generic (comprendre avec Object dedans)
et des casts rajoutés par le compilo quand on essaye d'acceder.
En fait, cela genere les casts que l'on ecrirait à la main
habituellement.
ArrayList a=new ArrayList();
a.add("toto");
String s=(String)a.get(0);
devient
ArrayList<String> a=new ArrayList<String>();
a.add("toto");
String s=a.get(0); // ici le code genere par le compilo
// est String s=(String)a.get(0);
>
> Yoz (Yagiz)
> http://www.erkans.com
Remi
|
|
Bruno Leroux wrote:
>
> Erik Mazoyer wrote:
>
>>...
>>
>>>3) La syntaxe va se compliquer énormément, même si ça semble
>>>
>>acceptable...
>>
>>Je pense que l'ajout sera peu douloureux (a part quand on commence
>>Java). Mais c'est aussi le cas en C++. On n'utilise pas les templates
>>tout de suite.
>>
> pour illustrer le propos de Cédric sur la complexification de la
> syntaxe, voici un exemple tirer de la spec (page 4) :
En fait, c'est une question d'habitude, ca fait un an que je programme
avec (Il existe une option dans le compilo fourni qui retransforme le code
écrit en code Java "normal"). Et je trouve ca particulièrement sain de
typé les Collections !!!. Entre autre, je joue aussi avec plein d'EJBs et
se retouver avec des interfaces dont les méthodes renvoie des "Collection"
sans autre forme de proces, je trouve ca debile.
>
> class Client {
> Seq<String> strs =
> new Seq<String>("a", new Seq<String>("b", new Seq<String>()));
sequence (au sens fonctionnel) de String
> Seq<Number> nums =
> new Seq<Number>(new Integer(1),
> new Seq<Number>(new Double(1.5),
> new Seq<Number>()));
la meme mes avec des entiers (ici de type statique Number mais
de type dynamique Integer).
> Seq<String>.Zipper<Number> zipper = strs.new Zipper<Number>();
On cre une inner-classe Zipper sur la sequence de string,
puis on appel la méthode zip() sur cette inner qui doit creer
une nouvelle séquence contanenant des pair String/Number.
> Seq<Pair<String,Number>> combined = zipper.zip(nums);
> }
>
> Bruno
|
|
> From: Remi Forax [mailto:forax@univ-mlv.fr]
> En fait, c'est une question d'habitude, ca fait un an que je
> programme avec (Il existe une option dans le compilo fourni
> qui retransforme le code écrit en code Java "normal"). Et je
> trouve ca particulièrement sain de typé les Collections !!!.
Je pense que personne ne conteste ce point. Depuis que je programme en
Java, j'ai tendance a coder de la facon suivante :
/**
* @returns a HashMap of (String employeeName, Employee employee)
*/
public HashMap findAllEmployees() { ... }
Pas besoin de me convaincre qu'une version typee serait plus robuste.
Mon argument allait dans le sens de l'analyse du compromis que les
generiques imposent. Et de ce point de vue, je pense qu'on va gagner un
peu et perdre beaucoup.
C'est de toute evidence une question d'interpretation, mais je suis pret a
parier que les Generiques ne seront jamais incorpores dans Java.
--
Cédric
|
|
Le 21 Mar 2002 Remi Forax a écrit :
> L'implémentation 1.2 de la specif sur les generics est sortie
> (si ca interresse qqun :)
> [...]
Une question de fénéant :
Sera-t-il possible de désigner des retours de méthode "indéfini",
style la méthode clone ?
Par exemple :
public <LaVraiClasseDeMonObjet> clone();
Merci (et bon week-end).
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
|
|
Le 22 Mar 2002 Cedric Beust a écrit :
>
> C'est de toute evidence une question d'interpretation, mais je suis pret
> a parier que les Generiques ne seront jamais incorpores dans Java.
>
Qui peut savoir ?... Moi, qui parle sans être même allé voir ces
generics (et de toutes façons j'ai complètement pomé mon user id et
password des earlyaccess), ce que je regrette, c'est que le langage
se rapproche des bonnes combines à la C++, au lieu de se rapprocher
des méthodologies logicielles.
Par exemple, il me semble que ces generics se rapprochent beaucoup de la
notion de "Pattern". En gros les générics disent "prend telle classe qui
manipule des objets, et remplace ces objets par des clients, tables,
poussettes, etc."
Pourquoi nos amis de Sun ne se disent-ils pas "Bon, on va essayer
d'inclure un langage de Pattern dans Java. " ?
Justement, cela tombe bien puisque la pratique Java se couvre de
Patterns qui se cachent. Pour les "beans", par exemple, on nous dit
"Prenez une classe, donnez lui un constructeur public sans argument,
rendez-la serializable, enfin utilisez 'set' pour désigner les setteurs et
'get' pour les getteurs : vous avez un bean". Pour les JNDI on nous dit
"Faites gaffe que les Context ont des Properties mais il ne faut surtout
pas les modifier, vous DEVEZ faire un clone pour les utiliser, sinon vous
ne respectez pas les règles !"
Cela ressemble à des règles de programmation, à des pratiques, à des
modèles que l'on reproduit en les modifiant un petit peu à chaque fois,
bref, à des patterns.
Plutot que de faire du C++<like>, j'aurai préféré préféré que Java se
rapproche des bonnes idées (parce qu'il y en a de mauvaises ! ) de
méthodes comme UML, ou de langages de Patterns (je ne sais même pas si ça
existe). Mais comme je parle sans rien savoir (au fait vous avez remarqué
que j'avais posé une question sur Xalan et les indentations et que
personne n'a répondu !?? Dans ces conditions si vous croyez que je peux
réfléchir sereinement à la philosophie logicielle ! ), peut être y a-t-il
des travaux en cours dans ce domaine ?
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
|
|
Cedric Beust wrote:
>>From: Remi Forax [mailto:forax@univ-mlv.fr]
>>
>
>>En fait, c'est une question d'habitude, ca fait un an que je
>>programme avec (Il existe une option dans le compilo fourni
>>qui retransforme le code écrit en code Java "normal"). Et je
>>trouve ca particulièrement sain de typé les Collections !!!.
>>
>
>Je pense que personne ne conteste ce point. Depuis que je programme en
>Java, j'ai tendance a coder de la facon suivante :
>
>/**
> * @returns a HashMap of (String employeeName, Employee employee)
> */
> public HashMap findAllEmployees() { ... }
>
>Pas besoin de me convaincre qu'une version typee serait plus robuste.
>
>Mon argument allait dans le sens de l'analyse du compromis que les
>generiques imposent. Et de ce point de vue, je pense qu'on va gagner un
>peu et perdre beaucoup.
>
Ben, je dirais que l'on gane bcp, mais
>
>
>C'est de toute evidence une question d'interpretation, mais je suis pret
>a parier que les Generiques ne seront jamais incorpores dans Java.
>
Oui, tu as raison. Pour l'instant, effectivement, le projet a été lancé ya
pas mal de temps, approximativement 3 ans, et ils avancent lentement.
Mais (il yu a toujours un mais) même sans les generics, il y a la
covariance du type de retour
qui elle DOIT être rajouté.
avec :
class Object {
Object clone() {...}
}
class A {
A clone() {...}
}
Si la covariance du type de retour est ajoutée, la méthode clone() de A
redéfinie la méthode clone() de Object.
Remi
|
|
Le 25 Mar 2002 Remi Forax a écrit :
>
> Si la covariance du type de retour est ajoutée, la méthode clone() de A
> redéfinie la méthode clone() de Object.
>
Cette modification a dose homéopathique me parait très bien venue.
Cela m'a toujours paru être une bêtise d'avoir à caster le retour des
méthodes style clone. J'imagine qu'on pourra faire pareil lors de
redéfinitions de ArrayList etc ? Cela donnera une lecture plus claire au
code, et rend quasiment inutile toutes les histoires de templates. A mon
avis, en tous cas.
A+.
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
