Discussion :

[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 ?)

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

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

[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

[romaintaz]

Je n'ai rien contre l'annotation, du moment que je n'ai pas à écrire (ou générer) mes getters et setters.
Mais alors autant la mettre directement dans le langage Java plutôt que d'utiliser des librairies externes...

[adiGuba]

Un petit contre... après une longue hésitation...

En fait le problème vient de l'existant car on casse un mécanisme pour le remplacer par un autre, mais qui devra rester compatible...

Bref cela risque de ne pas forcément être tip-top...

Si c'était une proposition pour un nouveau langage j'aurais surement dit oui mais là...

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.

Sauf qu'une annotation ne peut pas modifier le code source dans laquelle elle se trouve

a++

[verbose]

Voté pour. C'est vrai que certains éditeurs permettent d'écrire les getters et les setters en quelques click, mais je trouve que ça rendrait quand même le code plus lisible.

[romaintaz]

Voté pour. C'est vrai que certains éditeurs permettent d'écrire les getters et les setters en quelques click, mais je trouve que ça rendrait quand même le code plus lisible.

Oui, ce n'est clairement pas pour gagner quelques secondes à leur génération, mais voir 200 lignes de getters / setters dans un bean, je trouve ça indigeste...

[OButterlin]

Si ce n'est que ça, on pourrait imaginer un "include"

[le y@m's]

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

[nicorama]

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

Ben ca fera 44 erreurs à la compilation si ta property date de Mathusalem.

Le nombre de fois où j'ai modifié 44 fois de trucs... Le pire, c'est le jour où je me suis aperçu que j'avais inversé les Pattern Facade et Monteur. J'ai tout renommé, Netbeans a foutu des Monteur dans des package Facade, sans parler des lignes qui commencaient par Monteur maFacade . Bon j'arrête de pleurer sur mon sort

[bouye]

Pour MAIS des proprietes seules sans propagation de PropertyChangeEvent ca ne sert strictement a rien, hors c'est bien le fait de devoir a chaque fois reconstruire la gestion du PropertyChangeSupport + des ajout/retrait de listener + propagation d'evenements dans le setter pour chaque propriete qui est lourdingue (bien plus que de devoir ecrire les setter/getter qui ne sont que du copier/coller en fait).

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

[natha]

Pour MAIS des proprietes seules sans propagation de PropertyChangeEvent ca ne sert strictement a rien, hors c'est bien le fait de devoir a chaque fois reconstruire la gestion du PropertyChangeSupport + des ajout/retrait de listener + propagation d'evenements dans le setter pour chaque propriete qui est lourdingue (bien plus que de devoir ecrire les setter/getter qui ne sont que du copier/coller en fait).

+1
Et les IDE les génèrent facilement les getters/setters.
Je vote CONTRE.

[romaintaz]

Moi j'ai voté POUR en gardant à l'esprit que cette proposition a pour but de simplifier le code Java, et donc d'améliorer la lisibilité des classes, et non de proposer une nouvelle fonctionnalité à Java...

@benwit: J'ai pris JSF comme exemple, mais ce n'est pas le seul framework...
Maintenant, moi si JSF propose une annotation pour mes propriété par exemple, ça me va très bien !

[Alec6]

Ca apporte quoi sémantiquement une property par rapport à une variable d'instance ?

En faite c'est quoi ?

Je comprends pas si on cherche à simplifier l'écriture du code, ou la modelisation, dans notre paradigme objet.