Discussion :

[Thorna]

Personnellement, je pense qu'il s'agit d'une très mauvaise proposition!

Code :

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

1
2
3
4
5
import java.lang.Integer as Number;
import java.lang.Double as Real;
import java.lang.String as Text;
import java.io.File as ...;
...

Vous perdez vite toute cohérence, chacun peut faire sa soupe à lui...

Entièrement d'accord! Et donc contre.

[fabszn]

Je suis plutôt contre! Comme ca été dit plus haut :

on dirait du SQL
Ca va complexifier la lecture du code
Les IDEs gèrent de manière transparente les imports

La seule raison qui pourrait me faire voter pour (évoquée par adiGuba)
Cela permettrai de résoudre les problèmes de conflits d'import.
Mais ces cas là reste assez isolés (selon moi)

[Bollagain]

Contre.... car, encore une fois, cela n'apporte rien qu'un présumé confort qui plus nocif que favorable.

Au mieux, cette proposition apporte quelques secondes de confort pendant le codage (et encore ) ... secondes que l'on payera immanquablement par des céphalées prise, en phase de support, à remonter la pelote de laine du code pour savoir quel est le vrai objet qui se cache derrière un Alias.

Partant de là, pourquoi ne pas aussi ajouter que les Alias soient "hérités" (par exemple via les profiles des méthodes) et que l'on puisse aussi les utilisé pour faire du Casting.... histoire de rendre les chose encore plus drole.

Pour rebondir sur les discussions lancées par Bulbo et adiGuba, le coté structuré de Java me parait être un élément essentielle de qualité du langage.
C'est une tarte à la crème, mais en contraignant les développeurs à décrire précisément et explicitement ce qu'ils font, le langage oblige à plus de rigueur notement en ce qui concerne le comportement du programmes dans les innombrables cas hors du "Happy Flow".



Sur ce sujet, je note d'ailleurs que Java n'est pas, lui même,aussi exemplaire qu'il le pourrait sur ce sujet (cf. les horribles RunTimeException par exemple).

[fabszn]

Contre.... car, encore une fois, cela n'apporte rien qu'un présumé confort qui plus nocif que favorable.

Au mieux, cette proposition apporte quelques secondes de confort pendant le codage (et encore ) ... secondes que l'on payera immanquablement par des céphalées prise, en phase de support, à remonter la pelote de laine du code pour savoir quel est le vrai objet qui se cache derrière un Alias.

Partant de là, pourquoi ne pas aussi ajouter que les Alias soient "hérités" (par exemple via les profiles des méthodes) et que l'on puisse aussi les utilisé pour faire du Casting.... histoire de rendre les chose encore plus drole.

Pour rebondir sur les discussions lancées par Bulbo et adiGuba, le coté structuré de Java me parait être un élément essentielle de qualité du langage.
C'est une tarte à la crème, mais en contraignant les développeurs à décrire précisément et explicitement ce qu'ils font, le langage oblige à plus de rigueur notement en ce qui concerne le comportement du programmes dans les innombrables cas hors du "Happy Flow".



Sur ce sujet, je note d'ailleurs que Java n'est pas, lui même,aussi exemplaire qu'il le pourrait sur ce sujet (cf. les horribles RunTimeException par exemple).

Hello,

Tout à fait d'accord!

[pcaboche]

Sinon, on peut faire encore une autre proposition:

Code :

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

Dim MonImport AS MonAlias ;

Ah zut, on dirait du Visual Basic (en plus moche).

Plus sérieusement, je trouve que cette proposition est sans intérêt et peut se réveler dangereuse. Je suis d'accord avec la plupart des gens qui sont contre cette proposition (en particulier bulbo) et dont les arguments sont très pertinents.

Cette proposition n'apporte rien de nouveau, peut rendre le code rapidement incompréhensible, complexifie inutilement le langage, rend le langage plus difficile d'accès aux débutants, etc.

Je suis également d'accord avec ceux qui affirment que C# a apporté son lot de cochonneries inutiles et piégeuses (bulbo, encore une fois ). Ce n'est pas grand chose: juste des petits détails qui peuvent devenir assez lourds au quotidien alors qu'au départ il s'agit de fonctionnalités censées simplifier la vie du programmeur (comme c'est le cas ici).

En outre, je commence à me poser des question quant à l'intérêt de certaines propositions faites à propos du langage Java, la plupart n'étant que de mauvais de sucres syntaxiques qui complexifient le langage sans apporter de réelle innovation. Un langage doit rester simple pour être facilement abordable et utilisable.

Bande de conservateurs va !

Non mais oh ! Reste poli !

[Stef784ever]

Je trouve ca complique les choses pour un gain de temps pas evident car il faudrat ecrire un alias plutot que d'utiliser un CTRL+Espace

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

[nicorama]

Je trouve ca complique les choses pour un gain de temps pas evident car il faudrat ecrire un alias plutot que d'utiliser un CTRL+Espace

+1 - Les IDE ont fait beaucoup de progrès, même s'il ne faut pas pour autant que les langages restent sur leurs acquis

[zegreg]

A quand des propositions qui simplifieraient les choses ? Encore une fois question relecture de code ça va devenir un casse tête... Je suis contre...

[zegreg]

Re...

Je trouves que ce sont des propositions qui à vue d'œil sont "sympa"... Quand on programme chez soit, on aimerait un code probablement moins verbeu. Par contre, quand on est en entreprise, et que l'on doit relire/reprendre le code de qqun qui aurait utilisé à outrance ce genre de racoursis, désolé, mais ça va vite devenir n'importe quoi et d'illisible...

[w3blogfr]

Je suis contre, cette structure présente les défauts de VB. A savoir un manque de clairté, de plus, les éditeurs le font très bien.

[deltree]

Moi je trouve que ça comble un manque par rapport au C, celui de pouvoir paramétrer un type dans tout son code:
par exemple (de mémoire)

Code :

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

#define BOOLEAN int

Par contre, si on veut pouvoir l'inclure dans plusieurs fichiers, on est obligé de passer par une syntaxe du 2ème type.

Mais si on avait eu ça pour paramétrer les types Vector du java 1, on n'aurait pas eu besoin de tout casser pour passer aux ArrayList, idem pour les StringBuffer et les StringBuilder entre le 4 et la 5....

Enfin c'est anecdotique, je pense surtout aux framework "maison" qui nous imposent les types utilisés, et qui finissent par tout redéfinir, ici, on ne redéfini que des alias.

Cependant, j'ai suivi avec attention les problèmes de lisibilité, alors je suis partagé. peut-être simplement avec une norme tout en majuscule?

Code :

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

1
2
3
4
5
6
7
8
9
 
//mydomain/PROJECTLIST.java
class PROJECTLIST as ArrayList<String>;
 
//mydomain/UneClasse.java
import mydomain.PROJECTLIST
 
//dans une méthode
PROJECTLIST list = new PROJECTLIST();

Je suis surpris que la "as" choque certains parce qu'il rappelle SQL et VB. On peut aussi bien utiliser "isa" ou "alias", bref un keyword qu'on ajoute à la liste des extends, implements....

[tchize_]

pour, parce que, dans certains cas, çà peut s'avérer utile (allez ici, et comptez le nombre de EboFactory dans une api qui forme pourtant un "tout".

mais contre le fait d'ajouter un nouveau mot réservé (as ou autre), la notation '=' me conviens très bien. Le problème avec des clés comme 'as' ou 'alias', c'est que si tu veux faire passer un projet, disons de java 6 à java 7, pour bénéficier des trentes kilos de sucre syntaxique, ben il y a de forte chances que tes variables locales soient souvent nommées as (exemple, AbstractService as = ...) ou alias (une application de gestions d'utilisateurs par exemple). Je connais d'ailleurs une librairies qui a très mal supportée à l'époque l'apparition du mot clé enum, elle était pleine de 'Enumeration enum = ..... '

[Furikawari]

Toujours contre, toujours pour les même raisons : les EDI sont d'une grande aide, ça n'apporte rien au développeur, ça va rendre le code potentiellement plus complexe à comprendre, etc.

[fridobox]

Contre pour une clarté et une réutilisabilité du code.
Un bon nommage des classes doit empêcher d'avoir à se poser cette question.

[nicorama]

8 mois apres, je trouve cela encore plus horrible !

[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

[hibour]

J'aime bien les typedef ca raccourcit les nom de classes surtout avec l'utilisation des générique, donc j'opterai pour l'ajout d'un nouveau mot clé spécial typedef

typedef ArrayList<String> StringList;
typedef java.sql.Date SQLDate;

mieux vaut se rapprocher du C++ que du SQL ou du dot net (C#)
Cdlt

[fyngaell]

Bonjour,

Je suis loin d'être un expert, alors tout d'abord je n'ai pas voté, mais je préfère vous livrer une idée qui me parait éliminer quelques uns des défauts ou questionnements cités, soit en résumé :

1/ les noms de package peuvent être long (à lire pas à écrire, du moins avec un IDE genre Eclipse)
2/ les typedef peuvent rendre les choses très confuses si l'on saute d'un fichier à l'autre et que les noms utilisés sont communs aux deux fichiers, mais pas leur définition ;
3/ permettre ou non les types génériques à la suite du nouveau nom

D'où mon idée :

a) le typedef ne s'appliquerait qu'à des noms de package

Code :

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

1
2
3
import java.util as UtilPack;
import java.sql as SqlPack;

C'est sûr, avec ces packages-là on a pas un gain de caractères affichés énorme
b) les définitions des alias pourraient se voir incluses dans un fichier utilisé pour tout le projet.

Toutefois, si j'ai bien compris, c'est Sun qui propose des évolutions et nous pourrions donner notre préférence entre les solutions à celles-ci, ou émettre un véto sur l'évolution elle-même. Dans ce cas, j'aurai sans doute écrit pour rien... mais tant pis.

A bientôt

[Uther]

Disons que Sun n'est plus le seul responsable de l'évolution de Java.

Cependant la phase de consultation pour les évolutions de java 7 est terminée depuis quelque temps et le typedef n'à d'ailleurs pas été retenu.