Discussion :

[vbrabant]

Typedef, c'est permettre de créer une espèce d'alias ou de raccourcis.
Par exemple :

Proposition 1 :

Code :

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

1
2
3
4
5
import java.util.Map<String,String> as MyProperties;
import java.util.Map<String,T> as Lookup<T>;
// if we add BGGA function types[
import { double => double } as DoubleFcn;

Proposition 2 :

Code :

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

1
2
3
4
5
 
static class MyProperties = Map<String,String>;
static class Lookup<T> = Map<String,T>;
// if we add BGGA function types
static class DoubleFcn = { double => double };

[osopardo]

Généralement on ne fait pas vraiment attention aux imports, les EDI permettent même de les masquer automatiquement, la proposition 1 risque donc d'apporter une certaine confusion à la lecture du code.

[adiGuba]

Je suis plutôt pour la proposition 1, et cela permettrait de résoudre plus facilement des conflits de nom de classes.

Actuellement on est obligé d'utiliser le nom complet pour une des classes :

Code :

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

1
2
3
4
5
import java.util.Date;
 
...
Date date = new Date(); // java.util.Date
java.sql.Date sqlDate = new java.sql.Date(0L); // java.sql.Date

On pourrait donc faire ceci :

Code :

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

1
2
3
4
5
6
import java.util.Date;
import java.sql.Date as SqlDate;
 
...
Date date = new Date(); // java.util.Date
SqlDate sqlDate = new SqlDate(0L); // java.sql.Date

a++

[bobuse]

Comme osopardo, je me suis d'abord fait la réflexion que la prop 1 risque de ne pas être visible. Mais ceci dit, la prop 2 est un peu alambiquée et compliquée.

Ce qui est sûr, c'est que comme dit adiGuba, ce serait vraiment pratique. Ça fait partie des choses qui me manquent terriblement par rapport au Python, qui utilise la syntaxe de la première prop.

J'ai donc voté pour la 1, en me disant que les IDE pouvaient ensuite s'adapter pour rendre la chose visible Car c'est à l'IDE de s'adapter au langage, et non l'inverse !

EDIT : Argghhh, beaucoup de contre

[austin P.]

pouah quel horreur

si des "collisions" sur les noms arrivent, il faut changer le nom de la ou des classes. cela evite que l'on nomme de la même façon 2 classes qui ont une couverture technique/fonctionnnelle différente.

Déjà que trouver un nom de classe clair n'est pas simple mais en plus si on permet ça, la maintenance vas être sympa dans les années a venir...

[romaintaz]

J'ai voté contré parce que ça va clairement complexifier le code. Pour peu qu'une personne dans l'équipe définisse ses propres alias, ça va finir par être dur à lire le code.
Pour peu que l'on ait un vicieux, on va se retrouver avec des trucs complètement improbables, comme par exemple "échanger" le nom de 2 classes :

Code :

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

1
2
3
 
import mypackage.ClassA as ClassB;
import mypackage.ClassB as ClassA;

Je vois toutefois 2 avantages à cette proposition :
1. Comme l'a dit adiGuba, c'est vraiment bien dans le cas où l'on importe 2 classes de même nom mais de packages différents.
2. Ca pourrait être utilisé (détourné ?) pour améliorer l'obfuscation de code

Maintenant, si ça devait être implémenté, je préfèrerais la syntaxe 1 (ça fait un peu SQL, mais bon).

[bobuse]

si des "collisions" sur les noms arrivent, il faut changer le nom de la ou des classes. cela evite que l'on nomme de la même façon 2 classes qui ont une couverture technique/fonctionnnelle différente.

Déjà que trouver un nom de classe clair n'est pas simple mais en plus si on permet ça, la maintenance vas être sympa dans les années a venir...

Ça reste qu'une possibilité. Donc si tu ne veux pas chercher de noms différents, tu fais à l'ancienne avec le chemin complet.

[Mobius]

Je suis plutôt pour la proposition 1, et cela permettrait de résoudre plus facilement des conflits de nom de classes.

Actuellement on est obligé d'utiliser le nom complet pour une des classes :

Code :

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

1
2
3
4
5
import java.util.Date;
 
...
Date date = new Date(); // java.util.Date
java.sql.Date sqlDate = new java.sql.Date(0L); // java.sql.Date

On pourrait donc faire ceci :

Code :

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

1
2
3
4
5
6
import java.util.Date;
import java.sql.Date as SqlDate;
 
...
Date date = new Date(); // java.util.Date
SqlDate sqlDate = new SqlDate(0L); // java.sql.Date

a++

Je me réveil peut etre un peut tard mais bon me voila.

Je penses que l'exemple d'adiGuba est le seul valable dans tout ce que j'ai vue (Et peut etre aussi si tu as un NomDeClasseALaConARalonge dont tu ne veux pas que ca te pourrisse ton code)

Cependant, contraitement a ce qu'a dit adiGuba, je trouve que tu peux faire la même chose avec les deux syntaxes

On pourrait également faire ceci :

Code :

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

1
2
3
4
5
import java.util.Date;
static class SqlDate = java.sql.Date;
...
Date date = new Date(); // java.util.Date
SqlDate sqlDate = new SqlDate(0L); // java.sql.Date

La première solution est peut être plus simple à comprendre, plus condensé, et plus dans la logique des imports

[romaintaz]

Je me dis que si ça passe dans Java7, il serait intéressant que les IDE mette en évidence le fait qu'une classe a un alias.
Par exemple, en proposant de mettre une couleur particulière genre :

Code :

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

1
2
3
4
5
6
7
8
9
import java.util.Date;
import java.util.Date as Date2;

...
public void aMethod() {
    Date date = ...;
    Date2 date = ...;
}

[bmoussaud]

C''est la porte ouverte aux vieux demons du langage C:
import java.util.Map<String,String> as MyProperties;
Non ! Java est un langage Objet et il doit le rester !
Si c'est pour économiser 3 frappes de touches, les IDE modernes sont maintenant bien présent

[xavlours]

Pour paraphraser une signature, je dirai : "un code crade en C++ est humain, mais une véritable catastrophe nécessite un typedef". Encore que les pires horreurs combinent typedef, pointeurs et const, et on en est à l'abri en java, mais non. C'est la porte ouverte à toutes les fenêtres, et les grueeks (mi geek mi cochon) vont s'y ruer joyeusement.

Bon c'est vrai que les arguments d'adiguba tiennent la route, mais j'ai encore de trop mauvais souvenirs.

[cysboy]

Je suis pour !
Et celà pour les mêmes raisons qu'a emis adiGuba dans le spremières pages !

[nicorama]

J'aimerais bien truc du style :

Code :

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

1
2
3
4
5
 
MyChildList as ArrayList implements ChildList;
MyChildList myChildList=new MyChildList(){
   //implementation des fonctions de l'interface
}

Car pour l'instant je doit créer un package contenant les classes implémentant ChildList. Et je commence à avoir beaucoup de fichiers - ou alors ya une instruction Java que j'ai zappé.
MyChildList n'est pas une classe public à proprement parlé, mais pas vraiment privée non plus. il faudrait réécrire 'MyChildList as ArrayList implements ChildList;' chaque fois qu'on en a besoin, ou 'MyChildList as AbstracList<Eleve> implements ChildList;', tout polymorphisme, generics et autres trucs objets étant possibles.

[Jfern]

Je suis plutot a faveur pour la proposition 1 surtout lorsque il faut utiliser desux classes qui ont le meme nom.
Par exemple la classe Date.