Discussion :

[FranT]

Je suis pour. C'est quand même dommage de pouvoir écrire automatiquement une classe bean en Groovy (comme ci-dessous) alors qu'il faut se payer tous les accesseurs en Java.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class Person {
        firstName
        lastName
        address1
        city
        province
        postcode
}
 
p = new Person(firstName:'Ian', lastName:'Darwin', province:'Ontario')
 
println "Hello ${p.firstName} ${p.lastName}"

[azalsup]

j'ai voté pour mais il faudra améliorer la proposition

exemple si un attribut est déclaré comme etant une propriety
il faudra que le compilateur cree automatiquement deux methodes un get et un set

exemple avec un attribut valeur

creation automatique de deux methodes

this.valeur() retourne la valeur
this.valeur( blabla ) affecte l'attribut valeur

[gizmosup]

Comme beaucoup d'autre,
pour à condition de pouvoir overrider nos méthodes get/set si on a besoin.

Par défaut, je suis assez contre le système existant qui possède 2 possibilités le getter/setter classiques et les appels par réflexion, parce que si on créé un setter spécifique et que notre système passe par réflexion, et bien le traitement du setter ne sert à rien.

Ceci permettra peut être d'appeler les méthode surchargées dans tous les cas lorsqu'elle existent...

[pvoncken]

Contre, à force d'ajouter des fonctionnalités sans réel besoin on augumente la complexité du code.

Pour les fainéants eclipse génère automatiquement les getter/setter.

[gokud-o-matic]

Contre, à force d'ajouter des fonctionnalités sans réel besoin on augumente la complexité du code.

Pour les fainéants eclipse génère automatiquement les getter/setter.

pour moi, le besoin de cette fonctionnalité est réel. il améliore radicalement la lisibilité du code.

[bulbo]

pour moi, le besoin de cette fonctionnalité est réel. il améliore radicalement la lisibilité du code.

Comment une proposition proposant d'ajouter des méthodes "invisibles" les getter/setter, peut elle améliorer la lisibilité ?

Ce que tu ne vois pas tu ne le lis pas, et il est très facile à la lecture de manquer un mot clé au milieu d'une déclaration contrairement à deux méthodes qu'il est quand même plus dur de zapper.

Pas une meilleure lisibilité, juste une astuce de fainéant qui se paiera ailleurs (maintenance, évolutivité, debug) à mon avis

Bulbo

[gokud-o-matic]

Comment une proposition proposant d'ajouter des méthodes "invisibles" les getter/setter, peut elle améliorer la lisibilité ?

Ce que tu ne vois pas tu ne le lis pas, et il est très facile à la lecture de manquer un mot clé au milieu d'une déclaration contrairement à deux méthodes qu'il est quand même plus dur de zapper.

Pas une meilleure lisibilité, juste une astuce de fainéant qui se paiera ailleurs (maintenance, évolutivité, debug) à mon avis

Bulbo

nous parlons bien de propriétés, n'est-ce pas? si la déclaration de propriétés est bien lisible, elle ne sera pas pire qu'un getter et/ou un setter, surtout qu'il est possible de marquer ces getter et setter comme liés à la propriété avec une annotation.
je pense que ce sondage regroupe trop de points qui devraient être débattus séparément: l'existence de propriétés et la manière de les déclarer.
pour leur existence, je suis totalement pour. pour leur déclaration, je suis ouvert.

[hedes]

Je vote contre car je n'en vois pas l'utilité : supprimer l'obligation d'écrire des getter/setter c'est un peu comme rendre la propriété public, non ?
Le fait que le compilo génère des set/get, franchement,d'un point de vue relecture de code ou maintenance, je ne vois pas l'apport...


Finalement au fur et à mesure des simplifications proposées, on va se retrouver avec un langage proche de l'assembleur ou du bytecode

[Uther]

Non car on garde quand même le phénomène d'encapsulation qui est l'interet de la chose. Tu ne vois pas les getter et setters si tu ne juge pas utile de les redéfinir, mais ils sont bien présents.
Donc, tu ne te rapproche pas du bytecode, bien au contraire.

Avoir un code inutilement verbeux n'est pas pour moi un gage de qualité.

[jproto]

Il n'est pas question de rendre les getter/setter obligatoires puisque la génération implicite de ceux-ci par le compilateur ne serait appliquée que sur le mot clef "property".

De la sorte, cela ne reviens pas au même que d'appliquer une portée publique puisque cela oblige toujours les utilisateurs à passer par des fonctions (getter/setter) qui pourront par la suite être rédigée manuellement afin d'y ajouter une plus-value.

[LinkinSelim]

j'ai voté contre, parce que je ne sais pas comment on va ecrire des attributs readonly ou writeonly ou synchronized !!!

[jproto]

Pour moi, un attribut readonly le deviendrait parce que tu écris uniquement son getter (et comme il existe, le compilateur ne génère rien : ni getter, ni setter), et inversement pour le writeonly.
En revanche pour le synchronised, d'autres auront peut être plus d'idées que moi.

[gokud-o-matic]

Pour moi, un attribut readonly le deviendrait parce que tu écris uniquement son getter (et comme il existe, le compilateur ne génère rien : ni getter, ni setter), et inversement pour le writeonly.
En revanche pour le synchronised, d'autres auront peut être plus d'idées que moi.

pour la synchro, c'est tres simple. s'il y a un getter ou un setter, on peut les synchronizer de la maniere habituelle. si c'est un acces direct a un champ prive, ce n'est pas synchronisable; on synchronise au niveau de la methode appelante. Au pire, on n'utilise pas les acces directs quand on veut synchroniser.

[Uther]

J'ai retrouvé l'URL de la proposition qui avait été faite par Remi Forax.

Si c'est implémenté comme cela, ca devrait m'aller.

[peuhpeuh]

Pour mais pas n'importe comment!!

Le lien donné par Uther présente une solution qui parai tout a fait viable.

Autre solution et a mon sens la plus sympa, celle du c#:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
private String _test;
public String test
  {
    get
    {
      return _test;
    }
    set
    {
      _test = value;
    }
  }

On peut le générer facilement via l'IDE, on garde le contrôle sur les getters/setters, et l'emploi dans le code est un peu plus clair.

[jproto]

Personnellement, cette notation c# ne me séduit pas vraiment, et je ne suis pas convaincu que cela corresponde vraiment à ce qui est recherché dans cette proposition.

[denisC]

contre dans cet état. Je ne veux pas que par défaut tout mes attributs aient des getters / setters, dont je ne connaitrais même pas la visibilité.

Je verrais plutot une syntaxe de type annotation :

Code :

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

1
2
3
4
5
6
7
 
@GetSet(visibility=protected)
private String prop1;
 
@Set(visibility=protected)
@Get
private String prop2;

On pourrait s'en sortir avec 3 annotations (@Get, @Set et @GetSet), et un attribut de visibilité, qui par défaut serait a public.

De cette façon, par défaut, il n'y a aucun accesseurs, mais on peut mettre en place un getter/setter plublic standard juste avec une annotation.

Et une erreur de compilation si l'annotation rentre en conflit avec une méthode.

[dingoth]

Pour si on peut ajouter ses getters/setters de cette manière :

Code :

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

1
2
3
4
5
6
7
8
9
public property String maPropriété;
 
public property void setMaPropriété (String newMaPropriété) {
    ...
}
 
public property String getMaPropriété () {
    ...
}

Ceci permet de préciser que nous travaillons sur un getter/setter de propriété. Et ceci est nécessaire pour le compilateur, je crois.

Pour read-only, write-only, on pourrait faire quelque chose de simple, comme ceci, comme un code de méthode abstraite :

Code :

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

1
2
3
4
5
public property String maPropriété;
 
private property void setMaPropriété (String newMaPropriété);
 
private property String getMaPropriété ();

[dingoth]

Tout le monde n'a pas toujours accès à un IDE dernière génération pour faire de la génération automatique, malgré le JRE qui lui est de dernière génération.

Je pense notamment à... mon cas, où je développe en vi sur un serveur d'application tournant sur Java 6. J'aimerais tant passer à Eclipse que j'ai utilisé dans mon précédent emploi et que j'utilise dans mes projets, mais on ne me le permet pas (et non, pour le moment, j'ai pas envie d'apprendre la méga-ligne sed à taper qui pourrait me faire ça **caugh** automatiquement).

[gokud-o-matic]

Tout le monde n'a pas toujours accès à un IDE dernière génération pour faire de la génération automatique, malgré le JRE qui lui est de dernière génération.

Je pense notamment à... mon cas, où je développe en vi sur un serveur d'application tournant sur Java 6. J'aimerais tant passer à Eclipse que j'ai utilisé dans mon précédent emploi et que j'utilise dans mes projets, mais on ne me le permet pas (et non, pour le moment, j'ai pas envie d'apprendre la méga-ligne sed à taper qui pourrait me faire ça **caugh** automatiquement).

on t'impose vi contre ta volonte? ton boss veut eviter que tu sois productif ou quoi?