Discussion :

[gexian]

Contre pour une raison toute simple : on commence la déclaration par public. Je ne peux pas m'empêcher de penser qu'on part pas dans la bonne direction dès que je vois ça.

Code :

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

1
2
3
4
5
 
public class Person {
 public property String forename;
 public property int age;
}

Les getter et les setter peuvent paraître tous les mêmes au début, mais plus le projet avance ou quand on commence la maintenance il arrive vite qu'il y ai rajout de test à l'intérieur des setter ou d'initialisation dans les setters.

Je trouve qu'une partie non négligeable des propositions sur ce java 7 sont des raccourcis (dangereux) de code qui rendent le code moins clair.

[Furikawari]

Contre.

On est au 21ème siècle : les EDI se chargent très bien de générer puis masquer se genre de choses.
Pour moi la syntaxe d'un langage doit rester la plus simple possible et Java s'éloigne de plus en plus de ça...

[Uther]

Pour moi le fait qu'une EDI face quelque chose n'est pas une excuse pour que ce soit mal géré par le langage. Les properties sont clairement quelque chose d'indispensable en Java et le fait que ce ne soit pas géré directement par le langage lui même est une véritable lacune.

Et puis même avec Eclipse ou Netbeans pour nous aider à générer tout ce code, ça n'en reste pas moins une surcharge inutile, source de bug et de code peu lisible.

[Furikawari]

Est-ce que ça apporte une fonctionnalité nouvelle ? non.

Source de bug des getters et des Setters ?

Code peu lisible ?

Qu'on me dise "java aurait pu être conçu de sorte à avoir ça" je veux bien, mais tes arguments ne sont pas convaincants...

[Uther]

Est-ce que ça apporte une fonctionnalité nouvelle ? non.

Est ce que les generics apportent de nouvelle fonctionnalités? Pas vraiment c'est juste du sucre syntaxique, pourtant ça m'ennuie énormément de ne pas les avoir quand je travaille sur un projet limité en version 1.4.

Source de bug des getters et des Setters ?

Le principe même du getter/setter, n'est pas buggé.
Mais la duplication de code inutile augmente toujours le risque d'erreurs de programmation.
Par exemple, ça m'est arrivé d'avoir une faute de frappe qui fait que getter et setter ont un nom différent, ou une erreur de copier/coller où l'on a oublié de modifier le nom de la variable stockant la propriété.

Code peu lisible ?

Le code de certaines de mes classes est constitué à plus de 80% des setter/getters triviaux. Pour moi c'est clairement un gros défaut de lisibilité : une classe qui ne fait rien de particulier de devrait pas atteindre des centaines de lignes. Le code vraiment utile deviens nettement moins évident.
De plus comme on ne sait pas si un getter fait juste une affectation ou d'avantage, il faut prendre le temps de le vérifier si on veut éviter les mauvaises surprises.
Un des gros défaut de JAVA est qu'il est bien trop verbeux, et pour moi cette proposition d'évol, va dans le sens de corriger ça. C'est également le cas des closures.

Qu'on me dise "java aurait pu être conçu de sorte à avoir ça" je veux bien, mais tes arguments ne sont pas convaincants...

Oui et Java aurait également du être conçu de la sorte à avoir les génériques, heureusement qu'ils ont étés rajoutés par la suite.
Et puis ce ne serait jamais qu'un ajout pas un changement. Si ça plait pas, rien n'obligerait de l'utiliser.

[lex2004]

Pour! Mais il faudrait y associer une syntaxe plus riche que le simple mot clé property. N'oublions pas que toutes les propriétés ne mappent pas forcément des champs (certaines retournent le résultat de traitements complexes)