JDK 7: Proposition 12 : déclaration des propriétés

Pour mais, comme d'autres je pense qu'il manque une info du genre "lecture seule". Aussi il pourrait être intéressant d'avoir des infos genre "synchronized" et "invokeLater" (pour les composants Swing par ex).

Contre. Ca revient à casser le paradigme objet. On peut déjà déclarer les attributs publics et y accéder, si on a envie, mais la logique objet veut qu'on passe par des accesseurs/mutateurs et qu'on soit un minimum conscient de ce qu'on écrit. Là, on finirait par se retrouver en train d'invoquer des méthodes qu'on ne retrouve pas dans le code. Faut quand même savoir ce qu'on veut. Totalement contre !

J'ai une tendance à être pour mais j'ai quelques interrogations que personne n'a relevé.

Je suis totalement pour introduire le mot clé properties dans la définition d'une variable dans un contexte de refléxivité.

Cependant dans les codes appellants que va t'il se passer réellement ?

Lorsque je voudrais faire ceci : maVarDuBean.setVarDuBean("....") quel sera l'écriture avec cette nouveauté ? MonBean.maVarDuBean , comme si cette variable était déclarée en public :/

Contre

Actuellement il est tellement facile de générer automatiquement des getter/setter avec un IDE.

Contre.

Je préfèrerais :
- une annotation standard, genre @Property(read=public, write=protected) qui fasse planter la compiilation si nécessaire
- ou bien un EDI qui folde les getters/setters et affiche différemment les attributs.

Je suis a priori pour. Cependant la description est vraiment trop sommaire pour voir si c'est interessant, car il faut quelquechose de bien fait ou rien du tout.

Pour moi les points impératifs sont:

• Sucre syntaxique qui crée réelement le getter et le setter en respectant la norme en cours.
• Erreur de compilation s'il y a redéfinition sauvage du getter ou setter ou si on déclare une variable du nom de la proriété
• Possibilité de redéfinir le get et le set :
  
  • soit grace à une annotation @getter qui authoriserai de redéfinir getMyProperty sans erreur de compilation
  • soit un mécanisme comme en C# mais optionnel
• Création a la fois de getMyProperty() et isMyProperty() pour les boolean pour eviter les problèmes
• Possibilité de faire readonly/writeonly

Je vote pour la version annotations de Supersami2000 en page 1

j'insiste tout de meme que la propriete devrait etre tres configurable, comme dans C# ou delphi.

dans delphi, on note

Code:

---

1 2	maProp:property montype read field_ou_getter write field_ou_setter monTab[index]:property array of montype read getter write setter

---

et il est possible d'enlever le read ou le write pour definir l'accessibilite.
c'est un peu ennuyeux que l'on puisse mettre une variable ou une methode de la meme maniere.

pour java, je proposerai quelque chose du genre annotations:

Code:

---

1 2 3 4 5 6 7

@getter(getX) @setter(setX) public int x;   public int getX(){...} public void setX(int value){...} // parametre unique pour etre valide

---

bon, j'ai introduis un nouveau concept, celui de donner une methode en parametre dans une annotation.

autre possibilite par alias:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

property int x; // declaration de la propriete   private int monX;   @getter(x) public int getX(){ return monX;} // getter normal mais avec annotation @setter(x) public void setX(int value){monX=value;} //setter normal mais avec annotation. un seul argument autorise   // accepte aussi property y;   @getter(y) @setter(y) private int monY;   // ou sinon pour faire court @getset(y) private int monY

---

x serait donc cree comme propriete.
Ce dernier choix me parait bien, mais il faut bien verifier a l'unicite. une propriete ne peut avoir au plus qu'un seul getter et un seul setter

Citation:

---

Envoyé par eclesia

Contre. Imaginer que vous vouliez changer le nom de votre variable. le nom des get/set changera avec ... quel beau bordel ca fera.

---

Dans ce cas la tu effaces le mot-clé property et tu ecris toi-même les getters/setters (et puis on peut pas dire que ce soit un cas très répendu).
Je suis complètement pour, mais avec les mêmes réserves que vous. Il faut impérativement gérer le read/write peut-être simplement avec des mots clés supplémentaires:

Code:

---

1 2 3

property readproperty writeproperty

---

Je met aussi une option sur les annotations car ce serait aussi clair et ça permettrait d'inclure cette fonctionnalité au langage sans pour autant modifier le langage (vous vous souvenez que les annotations peuvent, entre autres, être utilisées comme un précompilateur pas vrai?).

Citation:

---

Envoyé par gokud-o-matic

autre possibilite par alias:

Code:

---

1 2 3 4 5 6 7 8 9

property int x; // declaration de la propriete   private int monX;   @getter(x) public int getX(){ return monX;} // getter normal mais avec annotation @setter(x) public void setX(int value){monX=value;} //setter normal mais avec annotation. un seul argument autorise

---

---

Oui mais alors là non ! Le but de la proposition est de simplifier le code pour les propriétés. Ce que tu proposes, c'est de garder le codage actuel (i.e. écrire soit même son getter et son setter) et en plus, d'utiliser le mot clé property ainsi que de 2 annotations, plus l'utilisation d'une variable privée qui sert à stocker la propriété (monX) :aie:
Où est la simplification là dedans ?

Citation:

---

Envoyé par romaintaz

Oui mais alors là non ! Le but de la proposition est de simplifier le code pour les propriétés. Ce que tu proposes, c'est de garder le codage actuel (i.e. écrire soit même son getter et son setter) et en plus, d'utiliser le mot clé property ainsi que de 2 annotations, plus l'utilisation d'une variable privée qui sert à stocker la propriété (monX) :aie:
Où est la simplification là dedans ?

---

ne melange pas tout. j'ai mis plusieurs examples d'utilisation en un.
ce que je veux c'est:
- donner la possibiliter de binder une propriété à une variable privée sans get/set
- donner la possibiliter d'utiliser un get/set pour une propriété
- pouvoir mixer les get/set et binding direct (cas très courant: un bind direct pour lire mais un set pour ecrire)
- introduire le moins possible de mots cles (juste un property pour declarer le champs et son type) pour ne pas casser la syntaxe existante
- la possibilité de limiter l'acces sans utiliser de mot clef supplementaire(pas de readwrite ridicule)
- ne pas oublier que les IDE font une grosse part du boulot de generation de code.
- eviter au max des {} car ils sont deja utilisés pour les classes anonymes.
- c'est inspiré un peu de JPA, donc pas du tout nouveau

example:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

property boolean enabled;   @getter(enabled) private boolean _enabled=false;   @setter(enabled) public void setEnabled(boolean valeur){ ... // du code metier ... _enabled=valeur; }

---

avec ca, on peut utiliser la propriété enabled en toute simplicité

Contre.
D'abord, à moins de l'implémenter vraiment d'une façon intélligente dans le compilateur, ça risque des casser un tas de code existant: je ne sais pas pour vous, mais perso, j'utilise le mot property à gogo comme nom de champs.

De plus, un autre tas de code Java est basée sur les getters/setters :arrow: tout solution de la famille properties doit implicitement ou explicitement générer des getters et setters :arrow: ça introduit de l'instrumentation (mais bon, je vous l'accorde, du compile-time weaving).

Autre chose: on l'a déjà evoqué avant: pour être vraiment utilisable, on doit pouvoir personnaliser les getters/setters. Il y'a l'approche Delphi :arrow: cool mais bavarde. Il y'a aussi celle du C#: pas mal, mais je crois pas que c'est beaucoup plus concis que les traditionnels getters/setters Java. Donc, à moins de se limiter au cas de getters/setters basiques, cette proposition risque de ne pas être vraiment concise en pratique.

Il était temps. Les propriétés font quand même partie du principe de l'encapsulation.

J'ai une nette préférence cette écriture :

Code:

---

[public, private ou protected]property Type nomObjet getter getNomObjet() [ou fNomObjet] setter setNomObjet() [ou fNomObjet];

---

C'est clair et précis.


nota, le terme getter peut etre remplacé par read et setter par write.

Citation:

---

Envoyé par zulot

Pour si on peut garder la possibilité de faire des getteur setteur.

---

Pour, tant que ce comportement ne s'applique que lorsqu'aucun getter/setter n'est défini. En fait, à la façon du constructeur par défaut implicitement généré par le compilateur lorsqu'aucun constructeur n'est défini pour une classe.

Citation:

---

Envoyé par covao

Il était temps. Les propriétés font quand même partie du principe de l'encapsulation.

J'ai une nette préférence cette écriture :

Code:

---

[public, private ou protected]property Type nomObjet getter getNomObjet() [ou fNomObjet] setter setNomObjet() [ou fNomObjet];

---

C'est clair et précis.


nota, le terme getter peut etre remplacé par read et setter par write.

---

et pour les proprietes de listes, comment tu fais? exemple, j'ai un Vector<String> que je veux mettre en propriete et que je veux y acceder comme dans un String[]. comment faire avec ta notation?
avec ta notation, j'imagine que ce serait, pour ne pas empecher les vrais arrays, comme ceci:

Code:

---

property Type[<Generic>] nomObjet[] [getter nomObjet|nomMethod] [setter nomObjet|nomMethod]

---

exemple

Code:

---

1 2 3 4 5 6

//declaration property String nom[] getter getNom setter setNom   //usage String monNom=obj.nom[i]; obj.nom[j]="autre chose";

---

j'enleve les () parce qu'elles ne font qu'induire en erreur, et j'ai mis les getter et setter en option pour definir les droits de lecture/ecriture. j'enleve aussi les private|public|... parce que une propriete devrait toujours etre publique, sinon autant acceder directement au field. Et puis, j'ai mis les [] apres le nomObjet pour signaler que c'est une propriete liste. S'il s'agissait d'une propriete simple d'un objet array statique, ce serait plutot un

Code:

---

property Type[] nomObjet...

---

exemple

Code:

---

property int[] liste getter...

---

j'ai aussi mis en option les generiques pour les classes qui l'utiliseraient. Au pire, les generiques pourraient etre une alternative temporaire aux proprietes listes que je propose. exemple:

Code:

---

property Vector<String> maListe getter...

---

Malheureusement, ca interdit un acces rapide aux valeurs.

Mais sinon, c'est effectivement une maniere elegante avec 3 mots clefs.

Pour ma part je suis contre. Je veux garde un contrôle total.

Exemple je ne veux que des getters et aucune setter. Je veux effectuer des contrôles sur les paramètres ( setter ). Ici je ne peux pas.

Citation:

---

Envoyé par dams77

Pour ma part je suis contre. Je veux garde un contrôle total.

Exemple je ne veux que des getters et aucune setter. Je veux effectuer des contrôles sur les paramètres ( setter ). Ici je ne peux pas.

---

Lis donc les derniers posts, ils intègrent cette possibilité

En fait, je ne voyais pas les choses comme ça.
Pour moi, cette notation doit juste permettre de ne pas avoir à écrire des getter/setter qui pour le moment n’ont aucune valeur ajoutée, tout en gardant la possibilité d’ajouter des contrôles plus tard en créant ses propres méthodes.

Les getter/setter seraient générés directement par le compilateur selon la condition suivante :
Il n’existe encore aucune des méthodes possédant la signature que le compilateur aurait exploité.

Dans le cas contraire, le compilateur ne fait rien.

Ainsi, si rien n’est déclaré explicitement, le compilateur fait son œuvre.
Dès que l’une de ces méthodes est créé, le compilateur nous fait confiance et ne génère plus rien lui-même. Nous gardons ainsi la possibilité de ne créer que des getter (par exemple).
A noter qu’à partir du moment où l’on a explicitement déclaré l’une de ces méthodes, la nouvelle notation n’a en fait plus lieu d’être.

Quoi qu’il en soit, cela permet de gagner du temps et d’alléger le code vis-à-vis des 38 variables d’instances de ta classe sur 42 pour lesquelles tu n’as aucun contrôle à réaliser (au moins pour le moment).

Chris.

Citation:

---

Envoyé par jproto

En fait, je ne voyais pas les choses comme ça.
Pour moi, cette notation doit juste permettre de ne pas avoir à écrire des getter/setter qui pour le moment n’ont aucune valeur ajoutée, tout en gardant la possibilité d’ajouter des contrôles plus tard en créant ses propres méthodes.

Les getter/setter seraient générés directement par le compilateur selon la condition suivante :
Il n’existe encore aucune des méthodes possédant la signature que le compilateur aurait exploité.

Dans le cas contraire, le compilateur ne fait rien.

Ainsi, si rien n’est déclaré explicitement, le compilateur fait son œuvre.
Dès que l’une de ces méthodes est créé, le compilateur nous fait confiance et ne génère plus rien lui-même. Nous gardons ainsi la possibilité de ne créer que des getter (par exemple).
A noter qu’à partir du moment où l’on a explicitement déclaré l’une de ces méthodes, la nouvelle notation n’a en fait plus lieu d’être.

Quoi qu’il en soit, cela permet de gagner du temps et d’alléger le code vis-à-vis des 38 variables d’instances de ta classe sur 42 pour lesquelles tu n’as aucun contrôle à réaliser (au moins pour le moment).

Chris.

---

c'est tout de même une vision très réductrice des propriétés. Et lorsqu'on voudra implémenter des propriétés de style tableau (parce que oui, c'est très utile et c'est inexistant sous java), il vaudra mieux avoir bien pensé les bases des propriétés pour une évolution possible.

Citation:

---

Envoyé par gokud-o-matic

c'est tout de même une vision très réductrice des propriétés. Et lorsqu'on voudra implémenter des propriétés de style tableau (parce que oui, c'est très utile et c'est inexistant sous java), il vaudra mieux avoir bien pensé les bases des propriétés pour une évolution possible.

---

Citation:

---

Envoyé par vbrabant

But: supprimer le fait d'écrire des setters et getters

Code:

---

1 2 3 4 5

public class Person { public property String forename; public property int age; }

---

---

Je te l’accorde, et je trouve effectivement intéressant d’étendre la réflexion.
Cependant, pour répondre à la question première, je ne suis pas convaincu d’avoir vraiment répondu à côté. Je n’ai initialement perçu aucune allusion à une manipulation de type tableau, ni à un souhait de l’aborder (au moins pour répondre au sondage POUR / CONTRE).

En revanche, maintenant que le sujet a été levé, cette perspective est intéressante, mais tel que tu le mentionnes toi-même, il serait dommage que cela soit au détriment des performances.

Chris

Je suis pour. C'est quand même dommage de pouvoir écrire automatiquement une classe bean en Groovy (comme ci-dessous) alors qu'il faut se payer tous les accesseurs en Java.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class Person { firstName lastName address1 city province postcode }   p = new Person(firstName:'Ian', lastName:'Darwin', province:'Ontario')   println "Hello ${p.firstName} ${p.lastName}"

---

j'ai voté pour mais il faudra améliorer la proposition

exemple si un attribut est déclaré comme etant une propriety
il faudra que le compilateur cree automatiquement deux methodes un get et un set

exemple avec un attribut valeur

creation automatique de deux methodes

this.valeur() retourne la valeur
this.valeur( blabla ) affecte l'attribut valeur

Comme beaucoup d'autre,
pour à condition de pouvoir overrider nos méthodes get/set si on a besoin.

Par défaut, je suis assez contre le système existant qui possède 2 possibilités le getter/setter classiques et les appels par réflexion, parce que si on créé un setter spécifique et que notre système passe par réflexion, et bien le traitement du setter ne sert à rien.

Ceci permettra peut être d'appeler les méthode surchargées dans tous les cas lorsqu'elle existent...

Contre, à force d'ajouter des fonctionnalités sans réel besoin on augumente la complexité du code.

Pour les fainéants eclipse génère automatiquement les getter/setter.

Citation:

---

Envoyé par ultrafil

Contre, à force d'ajouter des fonctionnalités sans réel besoin on augumente la complexité du code.

Pour les fainéants eclipse génère automatiquement les getter/setter.

---

pour moi, le besoin de cette fonctionnalité est réel. il améliore radicalement la lisibilité du code.

Citation:

---

Envoyé par gokud-o-matic

pour moi, le besoin de cette fonctionnalité est réel. il améliore radicalement la lisibilité du code.

---

Comment une proposition proposant d'ajouter des méthodes "invisibles" les getter/setter, peut elle améliorer la lisibilité ? 8O

Ce que tu ne vois pas tu ne le lis pas, et il est très facile à la lecture de manquer un mot clé au milieu d'une déclaration contrairement à deux méthodes qu'il est quand même plus dur de zapper.

Pas une meilleure lisibilité, juste une astuce de fainéant qui se paiera ailleurs (maintenance, évolutivité, debug) à mon avis

Bulbo ;)

Citation:

---

Envoyé par bulbo

Comment une proposition proposant d'ajouter des méthodes "invisibles" les getter/setter, peut elle améliorer la lisibilité ? 8O

Ce que tu ne vois pas tu ne le lis pas, et il est très facile à la lecture de manquer un mot clé au milieu d'une déclaration contrairement à deux méthodes qu'il est quand même plus dur de zapper.

Pas une meilleure lisibilité, juste une astuce de fainéant qui se paiera ailleurs (maintenance, évolutivité, debug) à mon avis

Bulbo ;)

---

nous parlons bien de propriétés, n'est-ce pas? si la déclaration de propriétés est bien lisible, elle ne sera pas pire qu'un getter et/ou un setter, surtout qu'il est possible de marquer ces getter et setter comme liés à la propriété avec une annotation.
je pense que ce sondage regroupe trop de points qui devraient être débattus séparément: l'existence de propriétés et la manière de les déclarer.
pour leur existence, je suis totalement pour. pour leur déclaration, je suis ouvert.

Je vote contre car je n'en vois pas l'utilité : supprimer l'obligation d'écrire des getter/setter c'est un peu comme rendre la propriété public, non ?
Le fait que le compilo génère des set/get, franchement,d'un point de vue relecture de code ou maintenance, je ne vois pas l'apport...


Finalement au fur et à mesure des simplifications proposées, on va se retrouver avec un langage proche de l'assembleur ou du bytecode :mouarf:

Non car on garde quand même le phénomène d'encapsulation qui est l'interet de la chose. Tu ne vois pas les getter et setters si tu ne juge pas utile de les redéfinir, mais ils sont bien présents.
Donc, tu ne te rapproche pas du bytecode, bien au contraire.

Avoir un code inutilement verbeux n'est pas pour moi un gage de qualité.

Il n'est pas question de rendre les getter/setter obligatoires puisque la génération implicite de ceux-ci par le compilateur ne serait appliquée que sur le mot clef "property".

De la sorte, cela ne reviens pas au même que d'appliquer une portée publique puisque cela oblige toujours les utilisateurs à passer par des fonctions (getter/setter) qui pourront par la suite être rédigée manuellement afin d'y ajouter une plus-value.

j'ai voté contre, parce que je ne sais pas comment on va ecrire des attributs readonly ou writeonly ou synchronized !!!

Pour moi, un attribut readonly le deviendrait parce que tu écris uniquement son getter (et comme il existe, le compilateur ne génère rien : ni getter, ni setter), et inversement pour le writeonly.
En revanche pour le synchronised, d'autres auront peut être plus d'idées que moi.

Citation:

---

Envoyé par jproto

Pour moi, un attribut readonly le deviendrait parce que tu écris uniquement son getter (et comme il existe, le compilateur ne génère rien : ni getter, ni setter), et inversement pour le writeonly.
En revanche pour le synchronised, d'autres auront peut être plus d'idées que moi.

---

pour la synchro, c'est tres simple. s'il y a un getter ou un setter, on peut les synchronizer de la maniere habituelle. si c'est un acces direct a un champ prive, ce n'est pas synchronisable; on synchronise au niveau de la methode appelante. Au pire, on n'utilise pas les acces directs quand on veut synchroniser.

J'ai retrouvé l'URL de la proposition qui avait été faite par Remi Forax.

Si c'est implémenté comme cela, ca devrait m'aller.

Pour mais pas n'importe comment!!

Le lien donné par Uther présente une solution qui parai tout a fait viable.

Autre solution et a mon sens la plus sympa, celle du c#:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

private String _test; public String test { get { return _test; } set { _test = value; } }

---

On peut le générer facilement via l'IDE, on garde le contrôle sur les getters/setters, et l'emploi dans le code est un peu plus clair.

Personnellement, cette notation c# ne me séduit pas vraiment, et je ne suis pas convaincu que cela corresponde vraiment à ce qui est recherché dans cette proposition.

contre dans cet état. Je ne veux pas que par défaut tout mes attributs aient des getters / setters, dont je ne connaitrais même pas la visibilité.

Je verrais plutot une syntaxe de type annotation :

Code:

---

1 2 3 4 5 6 7

@GetSet(visibility=protected) private String prop1;   @Set(visibility=protected) @Get private String prop2;

---

On pourrait s'en sortir avec 3 annotations (@Get, @Set et @GetSet), et un attribut de visibilité, qui par défaut serait a public.

De cette façon, par défaut, il n'y a aucun accesseurs, mais on peut mettre en place un getter/setter plublic standard juste avec une annotation.

Et une erreur de compilation si l'annotation rentre en conflit avec une méthode.

Pour si on peut ajouter ses getters/setters de cette manière :

Code:

---

1 2 3 4 5 6 7 8 9

public property String maPropriété;   public property void setMaPropriété (String newMaPropriété) { ... }   public property String getMaPropriété () { ... }

---

Ceci permet de préciser que nous travaillons sur un getter/setter de propriété. Et ceci est nécessaire pour le compilateur, je crois.

Pour read-only, write-only, on pourrait faire quelque chose de simple, comme ceci, comme un code de méthode abstraite :

Code:

---

1 2 3 4 5

public property String maPropriété;   private property void setMaPropriété (String newMaPropriété);   private property String getMaPropriété ();

---

Tout le monde n'a pas toujours accès à un IDE dernière génération pour faire de la génération automatique, malgré le JRE qui lui est de dernière génération.

Je pense notamment à... mon cas, où je développe en vi sur un serveur d'application tournant sur Java 6. J'aimerais tant passer à Eclipse que j'ai utilisé dans mon précédent emploi et que j'utilise dans mes projets, mais on ne me le permet pas (et non, pour le moment, j'ai pas envie d'apprendre la méga-ligne sed à taper qui pourrait me faire ça **caugh** automatiquement).

Citation:

---

Envoyé par dingoth

Tout le monde n'a pas toujours accès à un IDE dernière génération pour faire de la génération automatique, malgré le JRE qui lui est de dernière génération.

Je pense notamment à... mon cas, où je développe en vi sur un serveur d'application tournant sur Java 6. J'aimerais tant passer à Eclipse que j'ai utilisé dans mon précédent emploi et que j'utilise dans mes projets, mais on ne me le permet pas (et non, pour le moment, j'ai pas envie d'apprendre la méga-ligne sed à taper qui pourrait me faire ça **caugh** automatiquement).

---

on t'impose vi contre ta volonte? ton boss veut eviter que tu sois productif ou quoi?