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)
@+
Fabszn
Twitter : @fsznajderman
N'oubliez pas le bouton
Comment bien poser ses questions sur le forum
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
Twitter : @fsznajderman
N'oubliez pas le bouton
Comment bien poser ses questions sur le forum
Sinon, on peut faire encore une autre proposition:
Ah zut, on dirait du Visual Basic (en plus moche).
Code : Sélectionner tout - Visualiser dans une fenêtre à part Dim MonImport AS MonAlias ;
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.
Non mais oh ! Reste poli !
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
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
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.
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...
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...
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.
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)
Par contre, si on veut pouvoir l'inclure dans plusieurs fichiers, on est obligé de passer par une syntaxe du 2ème type.
Code : Sélectionner tout - Visualiser dans une fenêtre à part #define BOOLEAN int
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?
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....
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();
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 = ..... '
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.
Contre pour une clarté et une réutilisabilité du code.
Un bon nommage des classes doit empêcher d'avoir à se poser cette question.
8 mois apres, je trouve cela encore plus horrible !
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 :
La première solution est peut être plus simple à comprendre, plus condensé, et plus dans la logique des imports
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
Librairie d'accès LDAP en Java : LdapBeans
et pensez au tag
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
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
C'est sûr, avec ces packages-là on a pas un gain de caractères affichés énorme
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 import java.util as UtilPack; import java.sql as SqlPack;
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
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager