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).

[Uther]

Voté contre car, le typedef, c'est un truc que je déteste déja en C/C++, j'ai pas envie de me le retrouver en Java.

Je trouve vraiment que ça a tendence a rendre le code pas clair contrairement a son but d'original.

[bassim]

Le cas qu'a présenté adibuga est vraiment tres rare en Java, je crois !

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 :

+1

je suis contre moi aussi !

protégeons notre langage

[bobuse]

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;

Ouais, bof, tu sais, dans l'état, un vicieux pourrait déjà faire n'importe quoi, en surchargeant des méthodes qui appellent les mauvaises méthodes de la superclasse par exemple.

[adiGuba]

Le cas qu'a présenté adibuga est vraiment tres rare en Java, je crois !

Dans l'API standard oui... mais il y a un certain nombre de classe "Utils" dans les librairies externes

a++

[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.

[bobuse]

Bande de conservateurs va !

[bulbo]

Plutôt pour,

Utile en cas de conflits de nom, et tu n'as pas toujours le contrôle des noms des librairies que tu utilises comme l'a dit adiGuba.

Faire a l'ancienne c'est bien mais quand tu as des packages a rallonge, tu as vite des lignes de code de plus de 200 caractères et la lecture et super chaotique.

[Edit]
Pour la propal 1 en fait, il est normal de résoudre dans les imports les conflits .. des imports pour moi
[/Edit]

Bulbo

[Uther]

Apres lecture des commentaires, je vais modérer mon avis. C'est vrai que pour résoudre des conflits de nom c'est une bonne idée, mais seulement dans ce cas la à mon avis. Or les exemples donné pour illustrer la proposition montrent clairement que ce n'est pas dans cette optique que c'est prévu d'être utilisé.
Donc je dirais ok a condition d'interdire:
- les generics dans les imports
- deux imports d'une même classe même avec un alias différents.

Code :

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

1
2
import java.util.Map<String,String> as MyProperties;
import java.util.Map<String,T> as Lookup<T>;

non

Code :

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

1
2
import java.util.Map as UtilMap;
import com.roadmaps.Map as RoadMap;

oui

[nicorama]

Quelle horreur ! On se croirait dans du SQL, back in the 70's et les pattes d'eph !

[benwit]

Plutôt de l'avis d'Uther.

Je ne suis pas trop chaud mais je vais voté pour la une (surtout pour éviter que la proposition 2 soit retenue dès fois que ça passerait)

[natha]

Vu la proportion de débutants qui mettent énormément de temps à comprendre qu'il faut nommer les choses correctement pour qu'on comprenne un peu ce qu'il se passe, avec des propositions pareilles dans Java7 je vais passer 3x plus de temps à comprendre ce qui a été fait et ça ne m'enchante gère.

Pour un développeur plus expérimenté je dis pas, c'est bien pratique et j'aimerais pouvoir utiliser cette syntaxe (prop 1 ou 2 peu importe). Mais voilà, y a pas que des dev expérimentés.

[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

[Traroth2]

Si je comprends bien, la proposition 2, ça revient à introduire un troisième bloc préliminaire avant la classe, après le package et les imports. Pourquoi pas... Ca aurait l'avantage de la clarté, parce que la proposition 1, c'est un peu... confusant...