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 1 sur 3 123 DernièreDernière
Affichage des résultats 1 à 20 sur 60
  1. #1
    Expert Confirmé Sénior

    Inscrit en
    mai 2003
    Messages
    3 284
    Détails du profil
    Informations forums :
    Inscription : mai 2003
    Messages : 3 284
    Points : 9 776
    Points
    9 776

    Par défaut JDK 7: Proposition 11 : Typedef

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

    Proposition 1 :
    Code :
    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 :
    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 };
    Vincent Brabant

    Ne pas me contacter par MP ni par mail pour des questions techniques. Ma liste d'amis restera vide.

  2. #2
    Membre régulier Avatar de osopardo
    Inscrit en
    juillet 2005
    Messages
    92
    Détails du profil
    Informations personnelles :
    Âge : 32

    Informations forums :
    Inscription : juillet 2005
    Messages : 92
    Points : 72
    Points
    72

    Par défaut

    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.

  3. #3
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 196
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 196
    Points : 19 124
    Points
    19 124

    Par défaut

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

  4. #4
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    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

  5. #5
    Membre actif Avatar de austin P.
    Inscrit en
    juin 2004
    Messages
    181
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : juin 2004
    Messages : 181
    Points : 178
    Points
    178

    Par défaut

    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...
    En essayant continuellement on finit par réussir. Donc : plus ça rate, plus on a de chance que ça marche. (Jacques Rouxel : "Les shadoks")

  6. #6
    Rédacteur/Modérateur
    Avatar de romaintaz
    Homme Profil pro Romain Linsolas
    Java craftsman
    Inscrit en
    juillet 2005
    Messages
    3 737
    Détails du profil
    Informations personnelles :
    Nom : Homme Romain Linsolas
    Âge : 36
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2005
    Messages : 3 737
    Points : 6 683
    Points
    6 683

    Par défaut

    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 :
    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).
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

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

    Informations forums :
    Inscription : avril 2002
    Messages : 3 034
    Points : 5 887
    Points
    5 887

    Par défaut

    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.

  8. #8
    Membre expérimenté Avatar de bassim
    Homme Profil pro
    Ingénieur Réseaux
    Inscrit en
    février 2005
    Messages
    657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : février 2005
    Messages : 657
    Points : 533
    Points
    533

    Par défaut

    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

  9. #9
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    Citation Envoyé par romaintaz Voir le message
    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 :
    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.

  10. #10
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 196
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 196
    Points : 19 124
    Points
    19 124

    Par défaut

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

  11. #11
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    Citation Envoyé par austin P. Voir le message
    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.

  12. #12
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    Bande de conservateurs va !

  13. #13
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : février 2004
    Messages : 1 259
    Points : 1 777
    Points
    1 777

    Par défaut

    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

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

    Informations forums :
    Inscription : avril 2002
    Messages : 3 034
    Points : 5 887
    Points
    5 887

    Par défaut

    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 :
    1
    2
    import java.util.Map<String,String> as MyProperties;
    import java.util.Map<String,T> as Lookup<T>;
    non

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

  15. #15
    En attente de confirmation mail

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 984
    Points
    984

    Par défaut

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

  16. #16
    Rédacteur
    Avatar de benwit
    Inscrit en
    septembre 2004
    Messages
    1 670
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 1 670
    Points : 3 147
    Points
    3 147

    Par défaut

    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)

  17. #17
    Expert Confirmé
    Avatar de natha
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    2 346
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2006
    Messages : 2 346
    Points : 2 735
    Points
    2 735

    Par défaut

    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.
    Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
    De la bonne manière de poser une question (et de répondre).
    Je ne fais pas de service par MP. Merci (...de lire les règles...).
    Ma page dvp.com

  18. #18
    Rédacteur/Modérateur
    Avatar de romaintaz
    Homme Profil pro Romain Linsolas
    Java craftsman
    Inscrit en
    juillet 2005
    Messages
    3 737
    Détails du profil
    Informations personnelles :
    Nom : Homme Romain Linsolas
    Âge : 36
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2005
    Messages : 3 737
    Points : 6 683
    Points
    6 683

    Par défaut

    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 :
    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 = ...;
    }
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  19. #19
    Membre expérimenté
    Avatar de bmoussaud
    Profil pro Benoit Moussaud
    Inscrit en
    décembre 2003
    Messages
    218
    Détails du profil
    Informations personnelles :
    Nom : Benoit Moussaud
    Âge : 41
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : décembre 2003
    Messages : 218
    Points : 514
    Points
    514

    Par défaut

    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
    Benoit Moussaud - XebiaLabs - Automatisation des déploiements. Screencast & Demo

  20. #20
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 733
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 733
    Points : 5 775
    Points
    5 775

    Par défaut

    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...
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

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
  •