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).
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
et il est possible d'enlever le read ou le write pour definir l'accessibilite.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 maProp:property montype read field_ou_getter write field_ou_setter monTab[index]:property array of montype read getter write setter
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:
bon, j'ai introduis un nouveau concept, celui de donner une methode en parametre dans une annotation.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
autre possibilite par alias:
x serait donc cree comme propriete.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
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
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:
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?).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 property readproperty writeproperty
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)
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:
avec ca, on peut utiliser la propriété enabled en toute simplicité
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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; }
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 tout solution de la famille properties doit implicitement ou explicitement générer des getters et setters ç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 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 :
C'est clair et précis.
Code : Sélectionner tout - Visualiser dans une fenêtre à part [public, private ou protected]property Type nomObjet getter getNomObjet() [ou fNomObjet] setter setNomObjet() [ou fNomObjet];
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:
exemple
Code : Sélectionner tout - Visualiser dans une fenêtre à part property Type[<Generic>] nomObjet[] [getter nomObjet|nomMethod] [setter nomObjet|nomMethod]
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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";
exemple
Code : Sélectionner tout - Visualiser dans une fenêtre à part property Type[] nomObjet...
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 : Sélectionner tout - Visualiser dans une fenêtre à part property int[] liste getter...
Malheureusement, ca interdit un acces rapide aux valeurs.
Code : Sélectionner tout - Visualiser dans une fenêtre à part property Vector<String> maListe getter...
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.
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.
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager