Publicité

Affichage des résultats du sondage: Êtes-vous pour ou contre cette proposition ?

Votants
297. Vous ne pouvez pas participer à ce sondage.
  • Pour la proposition 1

    103 34,68%
  • Pour la proposition 2

    22 7,41%
  • Contre

    172 57,91%
+ Répondre à la discussion
Page 3 sur 3 PremièrePremière 123
Affichage des résultats 41 à 60 sur 60
  1. #41
    Membre chevronné
    Inscrit en
    décembre 2004
    Messages
    432
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 432
    Points : 607
    Points
    607

    Par défaut

    Citation Envoyé par Pill_S Voir le message
    Personnellement, je pense qu'il s'agit d'une très mauvaise proposition!
    Code :
    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.

  2. #42
    Membre Expert
    Avatar de fabszn
    Homme Profil pro Fabrice Sznajderman
    Développeur Java
    Inscrit en
    mars 2002
    Messages
    976
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Sznajderman
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2002
    Messages : 976
    Points : 1 600
    Points
    1 600

    Par défaut

    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


  3. #43
    Futur Membre du Club
    Inscrit en
    février 2008
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 13
    Points : 16
    Points
    16

    Par défaut

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

  4. #44
    Membre Expert
    Avatar de fabszn
    Homme Profil pro Fabrice Sznajderman
    Développeur Java
    Inscrit en
    mars 2002
    Messages
    976
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Sznajderman
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2002
    Messages : 976
    Points : 1 600
    Points
    1 600

    Par défaut

    Citation Envoyé par Bollagain Voir le message
    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!
    @+

    Fabszn
    Twitter : @fsznajderman

    N'oubliez pas le bouton
    Comment bien poser ses questions sur le forum


  5. #45
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro Pierre Caboche
    Inscrit en
    octobre 2005
    Messages
    2 649
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre Caboche
    Âge : 34
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 649
    Points : 8 923
    Points
    8 923

    Par défaut

    Sinon, on peut faire encore une autre proposition:
    Code :
    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.

    Citation Envoyé par bobuse Voir le message
    Bande de conservateurs va !
    Non mais oh ! Reste poli !

  6. #46
    Nouveau Membre du Club
    Inscrit en
    août 2002
    Messages
    117
    Détails du profil
    Informations forums :
    Inscription : août 2002
    Messages : 117
    Points : 36
    Points
    36

    Par défaut

    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

  7. #47
    Invité régulier
    Inscrit en
    avril 2006
    Messages
    18
    Détails du profil
    Informations forums :
    Inscription : avril 2006
    Messages : 18
    Points : 8
    Points
    8

    Par défaut A faveur pour la proposition 1

    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.

  8. #48
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 1 093
    Points
    1 093

    Par défaut

    Citation Envoyé par Stef784ever Voir le message
    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

  9. #49
    Nouveau Membre du Club
    Inscrit en
    août 2005
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 73
    Points : 38
    Points
    38

    Par défaut

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

  10. #50
    Nouveau Membre du Club
    Inscrit en
    août 2005
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 73
    Points : 38
    Points
    38

    Par défaut

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

  11. #51
    Membre du Club
    Profil pro Thibaut
    Inscrit en
    février 2008
    Messages
    123
    Détails du profil
    Informations personnelles :
    Nom : Thibaut

    Informations forums :
    Inscription : février 2008
    Messages : 123
    Points : 48
    Points
    48

    Par défaut On est pas des développeur VB

    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.

  12. #52
    Membre éclairé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 300
    Points
    300

    Par défaut Utile pour le paramétrage de type?

    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.

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

  13. #53
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro David Delbecq
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 772
    Détails du profil
    Informations personnelles :
    Nom : Homme David Delbecq
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 772
    Points : 41 243
    Points
    41 243

    Par défaut

    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 = ..... '
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  14. #54
    Inactif
    Inscrit en
    septembre 2008
    Messages
    357
    Détails du profil
    Informations forums :
    Inscription : septembre 2008
    Messages : 357
    Points : 439
    Points
    439

    Par défaut

    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.

  15. #55
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2008
    Messages
    20
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mars 2008
    Messages : 20
    Points : 23
    Points
    23

    Par défaut Arg

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

  16. #56
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 1 093
    Points
    1 093

    Par défaut

    8 mois apres, je trouve cela encore plus horrible !

  17. #57
    Membre éprouvé Avatar de Mobius
    Inscrit en
    avril 2005
    Messages
    463
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 463
    Points : 457
    Points
    457

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    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 :
    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 :
    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 :
    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
    Librairie d'accès LDAP en Java : LdapBeans
    et pensez au tag

  18. #58
    Membre éclairé
    Profil pro
    Inscrit en
    mars 2008
    Messages
    338
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2008
    Messages : 338
    Points : 397
    Points
    397

    Par défaut

    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

  19. #59
    Invité de passage
    Profil pro
    Inscrit en
    mars 2009
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2009
    Messages : 7
    Points : 3
    Points
    3

    Par défaut un moyen terme

    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 :
    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

  20. #60
    Expert Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 071
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 071
    Points : 6 745
    Points
    6 745

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •