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