Discussion :

[bassim]

Je suis pour si toutes les propositions précédentes sont présentes

[eclesia]

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

[bulbo]

Un tout petit petit pour ..

D'ailleurs ça doit être faisable déjà aujourd'hui avec des assertions.

Pas un gain énorme sauf quand on doit écrire un javabean stupide a la mano, mais la plupart du temps on passe par un framework X ou Y aujourd'hui donc ..

Faudrait que la javadoc suive aussi dans ce cas et ajoute les méthodes invisibles dans le code automatiquement.
Pour moi inutile de donner la priorité a un getter écrit a la mano par exemple, il faut dans ce cas virer le mot clé property et faire les choses correctement en contrôlant le getter et le setter.

Bulbo

[romaintaz]

Pour moi inutile de donner la priorité a un getter écrit a la mano par exemple, il faut dans ce cas virer le mot clé property et faire les choses correctement en contrôlant le getter et le setter.

Je suis tout à fait d'accord, c'est bien plus propre. Maintenant, rien ne t'empêche de définir un setter (ou un getter) sur une property, et dans ce cas, j'estime qu'il est important que le setter (getter) défini manuellement soit prioritaire...

[bulbo]

Je suis tout à fait d'accord, c'est bien plus propre. Maintenant, rien ne t'empêche de définir un setter (ou un getter) sur une property, et dans ce cas, j'estime qu'il est important que le setter (getter) défini manuellement soit prioritaire...

Tu peux aussi avoir une erreur de compil qui te dit que tu essayes de redéfinir un get/set d'une property et je préfèrerais ça. Imagine tu fais une faute de frappe dans le nom de ta méthode .. du coup tu n'appelleras pas la bonne et en regardant ton code tu auras l'impression que si ..

Alors que si 'property' get/set auto sinon get/set a la mano, tu es sur de pas te planter..

Bulbo

[OButterlin]

Il semblerait que toutes ces propositions aient un point commun... que le programmeur en code un minimum, quitte à rendre le code plus incompréhensible par des "opérations automatiques"
Je finirais presque par être contre toutes les propositions... sauf peut-être le switch String... et là, il faudra qu'on m'explique comment rendre indépendant le test d'un charset... (en le fixant peut-être ?)

[bassim]

Il semblerait que toutes ces propositions aient un point commun... que le programmeur en code un minimum, quitte à rendre le code plus incompréhensible par des "opérations automatiques"

moi aussi, je trouve qu'il n y a vraiment rien de révolutionnaire dans ces propositions (pas comme les Generics dans java 5)

[romaintaz]

Tu peux aussi avoir une erreur de compil qui te dit que tu essayes de redéfinir un get/set d'une property et je préfèrerais ça. Imagine tu fais une faute de frappe dans le nom de ta méthode ..

Justement, si tu fais une faute de frappe (genre getTurc() pour une propriété truc), comment le compilateur va savoir que tu redéfinis un getter (setter) ? Le coup de l'exception ne servirait à rien dans ce cas !

[heid]

Justement, si tu fais une faute de frappe (genre getTurc() pour une propriété truc), comment le compilateur va savoir que tu redéfinis un getter (setter) ? Le coup de l'exception ne servirait à rien dans ce cas !

Une petite annotation avec le nom du champ que tu redéfinis non?

[bulbo]

Justement, si tu fais une faute de frappe (genre getTurc() pour une propriété truc), comment le compilateur va savoir que tu redéfinis un getter (setter) ? Le coup de l'exception ne servirait à rien dans ce cas !

Si tu sais que property = set/get automatique tu ne vas pas chercher une méthode dans ton code qui fait ça, contrairement au cas ou ce serait possible.

Si tu te plantes de nom pour un setter définis a la main tu as deux cas ensuite:

- tu appelles toujours avec la bonne ortho -> tu utilises bien la property
- tu appelles avec le mauvais nom aussi (la tu cherches les problèmes ) et un IDE classique te redirigeras sur la méthode appellée

Dans tout les cas je suis pas un grand grand fan de ce truc quel que soit son implémentation, surtout qu'un coup d'annotation et tu peux déjà écrire dans ton code aujourd'hui:

Code :

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

1
2
@bean_property
private String name

et générer avec l'annotation le code qui va bien pour faire ce que tu veux.

Bulbo

[le y@m's]

Un petit pour mais à condition que cela soit personnalisable (niveaux de visibilité, read/write, ajout de code spécifique).

[gokud-o-matic]

petit pour parce que les properties façon delphi et C# sont un très bon moyen de coder de maniere encore plus abstrait.

En contre partie, j'aime bien le standard de Java de tout faire commencer par get et set car ceci combiné à la completion automatique de certains IDE me permettent de savoir tout de suite la liste des champs, quelles champs je peux toucher et comment. mais si netbeans me dit si telle prop' est read ou write, alors volontiers pour.

[woodwai]

Contre.

Le but des setter et des getter été de pouvoir, de manière transparente, apporter des traitements lors du get et du set.
D'une certaine manière, c'est un contrat, on dit à celui qui utilise notre classe, tu peut récupérer la valeur par getProperty(), mais il ne sais pas si cette property est juste la valeur de l'attribut property ou autre chose.

Pour moi, c'est l'intérêt du principe de Javabean.
Sinon, on fait juste des attributs public!

[romaintaz]

Contre.

Le but des setter et des getter été de pouvoir, de manière transparente, apporter des traitements lors du get et du set.
D'une certaine manière, c'est un contrat, on dit à celui qui utilise notre classe, tu peut récupérer la valeur par getProperty(), mais il ne sais pas si cette property est juste la valeur de l'attribut property ou autre chose.

Pour moi, c'est l'intérêt du principe de Javabean.
Sinon, on fait juste des attributs public!

Pas complètement d'accord avec ça...
Prennons un framework comme JSF. Si je fais "monBean.maPropriete" dans une page XHTML (ou JSP), alors JSF va chercher à utiliser getMaPropriete() et setMaPropriete() et lancera une erreur si je mets juste la visibilité de maPropriete publique, sans fournir son setter / getter.
Si je me retrouve avec 30 propriétés dans mon bean, je vais devoir écrire (ou générer) 60 méthodes, ce qui emcombre (pour rien selon mon avis) ma classe Java...

[benwit]

Je suis de l'avis de Woodwai.

Quant à la remarque de romaintaz, même si je comprend son ennui, c'est LE problème de JSF. C'est JSF qui force l'encapsulation des données et ça devrait être paramétrable si c'est n'est pas le cas.

[ludosoft]

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).

[Traroth2]

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 !

[ReaM]

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 :/

[djo.mos]

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.

[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 :

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

   [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.