Discussion :

[joseph_p]

Bonjour

Je vous écris concernant la RFE (Request for Enhancement) 4228585 .

En gros, elle parle d'avoir des accesseurs automatiquement généré pour les variables.

Dans la proposition, il est question d'avoir une nouvelle propriété ou quelque chose d'équivalent. Ceci dit, le statut exact du traitement de cette demande est très floue.

Pour ma part, je trouve qu'avoir des accesseurs automatiquement générés serait un grand gain. Le principe d'encapsulation des variables serait alors réellement vérifier, et non approximativement comme actuellement...

Est ce que je rate quelque chose ? Etes vous d'accord (si oui... votez pour la RFE !!) ? Etes vous contre ? Pourquoi ?

Comme dirait Roumen Strohl : ZedroS, on a quest to make Java rocks

[professeur shadoko]

point important: les accesseurs/mutateurs ne doivent pas être automatiquement public (il faut que le programmeur choisisse)
de plus pas pertinent pour des membres qui seraient final!

j'ai cru comprendre qu'en C# (vade retro satanas) c'est pas trop mal conçu: on décrit les accesseurs/mutateurs et leur visibilité, le compilateur remplace alors dans le code courant les appels direct par des appels aux accesseurs/mutateurs.
à mon (très humble) avis ceci n'a d'intérêt que dans des objets pour lesquels des soucis du style interception peuvent se produire....
Donc, pour une fois -mais c'est la dernière hein! - peut être ok pour une syntaxe à la C# mais totalement optionelle et à la discretion du programmeur (j'ai une sainte horreur des "facilités d'écriture").

[adiGuba]

Salut,


Pour info, sur le billet En Vrac du blog du 8 décembre, il y a un lien vers le blog de Danny Coward qui parle du JDK7 et des fonctionnalitées qui sont à l'étude :

• Le blog : http://blogs.sun.com/dannycoward/ent...se_7_caught_on
• Le PDF sur Java 7 ~350Ko : http://blogs.sun.com/dannycoward/res...Prague_JUG.pdf

Dans le PDF il y a une partie sur de nouvelles fonctions du langage qui sont à l'étude (mais cela ne signifie en aucun cas que ce sera forcément intégré), et on y parle brièvement de cela (pas exactement de la même manière toutefois) !

Ceci :

Code :

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

1
2
3
private String foo;
public String getFoo() {..}
public void setFoo(String foo){..}

Pourrait être remplacé par ceci :

Code :

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

public property String foo;

J'avait également déjà vu une autre version basée sur les annotations, de mémoire (car je n'ai pas le lien sous la main) :

Code :

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

1
2
private @Property() String foo1;
private @Property(Access.READ_ONLY) String foo2;

Perso, je pense que cela peut être une bonne idée, à condition que cela génère des méthodes setter/getter standard, et qu'il soit toujours possible de les codé soit-même (sinon ils n'ont plus aucun intérêt). Il serait bien également de pouvoir y ajouter la gestion d'un PropertyChangeEvent...

j'ai cru comprendre qu'en C# (vade retro satanas) c'est pas trop mal conçu: on décrit les accesseurs/mutateurs et leur visibilité, le compilateur remplace alors dans le code courant les appels direct par des appels aux accesseurs/mutateurs.

Hum... personnellement cela ne me plait pas trop, car il s'agit d'une syntaxe simple (et qui sera donc utilisé surtout par les débutant), alors que derrière cela utilise des concepts un peu plus compliqué... et que comme beaucoup de facilité d'écriture cela peut provoquer des problèmes dû à la méconnaissance des méchanismes cachés...



Par contre le document PDF cité plus haut proposait une solution alternative en utilsiant l'opérateur -> du C/C++ (mais d'une manière différente), afin de pouvoir remplacé le code suivant :

Code :

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

a.setFoo(b.getFoo());

Par ceci :

Code :

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

a->Foo = b->Foo;

Je suis un peu sceptique (il faudrait voir à l'usure) mais ca pourrait être intérressant (bien entendu le bytecode généré devra être strictement le même).


a++

[professeur shadoko]

il y a un lien vers le blog de Danny Coward qui parle du JDK7 et des fonctionnalitées qui sont à l'étude :

• Le blog : http://blogs.sun.com/dannycoward/ent...se_7_caught_on
• Le PDF sur Java 7 ~350Ko : http://blogs.sun.com/dannycoward/res...Prague_JUG.pdf

merci pour le lien
vu
apparement le sucre syntaxique serait limité aux seuls Beans.

Par contre j'aime bien dans ce document le fait qu'on semble enfin se préoccuper de l'inexistence de la notion de publication... mais il faut voir les détails de ces super-packages

à suivre

[adiGuba]

apparement le sucre syntaxique serait limité aux seuls Beans.

A la notion de beans (donc un simple objet Java sérialisable avec des accesseurs pour ses attributs), à ne pas confondre avec les EJB

Par contre j'aime bien dans ce document le fait qu'on semble enfin se préoccuper de l'inexistence de la notion de publication... mais il faut voir les détails de ces super-packages

Il s'agit de la JSR-277 qui couvre un aspect plus large (nouveau format d'archive), dont la première early draft a déjà été publié : http://jcp.org/en/jsr/detail?id=277


a++

[joseph_p]

Merci pour vos intéressantes réponses

Sans rentrer de le détail de la mise en oeuvre, je trouve perso que rien que le principe est une chose importante. Ainsi, l'encapsulation serait réelle et permettrait ainsi vraiment de faire des mises à jour transparentes, au moins pour les éléments attributs sans accesseurs particuliers.

Actuellement, un type primitif en tant qu'attribut dans une classe est tout sauf aisément modifiable. Ou est l'encapsulation la ? N'est ce pas un principe important ?

Avoir automatiquement tous les attributs (de type primitif ou dérivés de la classe Object) accédés via des accesseurs aideraient beaucoup à refactoriser/modifier après coup. Enfin, il me semble :$ Je ne suis pas si sûr en fait.

Qu'en dites vous ?

[professeur shadoko]

Avoir automatiquement tous les attributs (de type primitif ou dérivés de la classe Object) accédés via des accesseurs aideraient beaucoup à refactoriser/modifier après coup. Enfin, il me semble :$ Je ne suis pas si sûr en fait.

tout dépend de ce que tu appelles attribut.
je ne suis pas d'accord pour les variables membres: certaines ne doivent pas être accessible par l'API et d'autres doivent pouvoir évoluer indépendament de l'API (c'est une part importante de l'idée d'encapsulation)
exemple (stupide): imagine une classe Date qui a des attributs jour, heure etc.
supposons que l'on ait l'accesseur getHeure() , rien ne m'empêche ensuite de supprimer la variable membre "heure" et de remplacer à l'intérieur de ma classe toutes mes valeurs par un seul "long" ... mais je laisse getHeure() dans l'API. Donc ici il y a distinction entre l'attribut "heure" et les variables membres : le champ "heure" disparait. après cette modification avoir un accesseur pour mon champ de type "long" ne s'impose pas.
conclusion: je suis opposé aux facilités syntaxiques qui ne laisseraient pas le programmeur maître de son design (par contre l'idée de C# mentionnée ci-dessus va dans le sens inverse: elle favorise les "cuts", c'est le code d'uitlisation des variables membres qui est transformé de manière à passer par des accesseurs -qui peuvent être privés!-).