Discussion :

[bouye]

Oui pour le '#'. L'utilisation du '.' porte trop a confusion avec les membres publiques de la classe et les programmeurs venant du C/C++ trouveront bizarre l'usage du '=>'.

[gokud-o-matic]

pour la 1 ou autre.
en tous cas pas la 2 qui me donne l'impression de déplacer ou d'affecter un objet vers un autre. je suis pas programmeur C et quand je vois a=>b, je comprends "a va vers b". pareil pour d'autres langages qui introduisent les ->

ni la 3 qui est gros et voyant comme tout. le point est la norme de séparation entre classe et membres dans java. introduire autre chose ne ferait que casser la norme.

[woodwai]

Contre.

On utilise un attribut public si on veut faire ça.
Pour moi, ça viole le principe du JavaBean

[heid]

Contre.

On utilise un attribut public si on veut faire ça.
Pour moi, ça viole le principe du JavaBean

Il faut bien comprendre que ce n'est qu'une astuce du compilateur et que le code final est le même. Vous appellerez le getter/setter de façon transparente c'est tout. Le JavaBean peut donc retirer sa plainte pour viol

[benwit]

Contre aussi.

[romaintaz]

J'ai voté pour la proposition #1, mais après réflexion, j'aurais plutôt dû voter contre

[JoloKossovar]

Clairement contre les 3 et au final encore plus contre le '.'.
Ca ne ferai que rendre le code plus confu, et vive les get/set !

[Floréal]

Cela permet il, comme en .Net d'écrire du code que peut impliquer l'accès à de telle propriété?
exemple bidon, pour compter les accès:

Code :

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

1
2
3
4
5
6
7
8
9
class Toto
{
  private int compteur;
  private String uneChaine_;
  public property String uneChaine {
    get { compteur++; return uneChaine_; }
    set { compteur++; uneChaine_ = uneChaine; }
  }
}

[ludosoft]

Je préfère la 1 car ça ressemble à ce que j'ai connu quand je développais des composants graphiques avec C++ Builder. Je pouvais utiliser les propriétés directement comme une variable (comme dans la proposition 1 quoi).

[elmor]

Contre

si le champ est privé je ne vois pas pourquoi on devrait pouvoir y avoir accés grace ou point ou autre.

Ajouter une syntaxe complexifierai de facon inutile JAVA.

De plus le "." ne nous indique pas si on peut ou pas modifier la valeur alors qu'avec un set ou un get ...

Surtout que de nos jours avec les IDE et l'autocompletion...

[heid]

Code :

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

1
2
3
maval.x = maval1.y+maval2.z;
 
maval.setX(maval1.getY() + maval2.getZ());

Quel est le plus lisible selon vous?

[Uther]

Je suis pour l'acces simplifié au propriétés et j'ai voté pour le "#" car je pense qu'il faut absolument faire la différence avec un attribut classique. Ceci dit c'est vrai qu'il fait un peu trop mastodonte.

Le problème du "=>" c'est qu'il implique une notion de déplacement ou de conséquence. en plus ca rapele le "->" qui a une signification particlière en C++.

Je pense que le "°" aurait été un meilleur choix mais vu que ce n'est pas un caractère ascii standard, ca n'irait pas. Le "`" serait aussi un bon choix vu que c'est un carractère ascii standard.

[bassim]

Je pense que le "°" aurait été un meilleur choix mais vu que ce n'est pas un caractère ascii standard, ca n'irait pas. Le "`" serait aussi un bon choix vu que c'est un carractère ascii standard.

je propose le @

[gokud-o-matic]

je propose le @

et pourquoi pas ‡ ou ¥ ou encore þ ou encore ‰

[zais_ethael]

Contre, autant c'est utile en C#, autant ça l'est parceque cette fonctionnalité est incluse au langage depuis le début. Je suis sur que ça dénaturera la syntaxe tot ou tard.

[Uther]

je propose le @

et pourquoi pas ‡ ou ¥ ou encore þ ou encore ‰

Je vois pas en quoi "`" serait plus idot que "#", d'autant que c'est un caractère ASCII standard. L'aspect qu'il ne soit pas courrament utilisé fait justement que ce n'est pas genant.
Le @ a bien déjà été ajouté pour les annotations.

[djo.mos]

Contre.
J'ai déjà voté contre le concept de property, donc ce la va de soi que je suis aussi contre l'accès simple aux properties

[phantomass]

Moi je suis assez pour.
En fait le langage Java a imposé une regle de conception assez hideuse.

Alors oui aujourd'hui tous nos IDE favoris générent des getters/setter inutiles.
Sincèrement dans la grande majorité des cas le getter/setter se contente de renvoyer de manière stricte l'attribut sous jacent.
A l'occasion le getter/setter se permet un contrôle une transformation.
C'est très flagrant pour les "DataObjects".
Moi je suis pour l'ajout de ce sucre syntaxique.

[bulbo]

Moi je suis assez pour.
En fait le langage Java a imposé une regle de conception assez hideuse.

Alors oui aujourd'hui tous nos IDE favoris générent des getters/setter inutiles.
Sincèrement dans la grande majorité des cas le getter/setter se contente de renvoyer de manière stricte l'attribut sous jacent.
A l'occasion le getter/setter se permet un contrôle une transformation.
C'est très flagrant pour les "DataObjects".
Moi je suis pour l'ajout de ce sucre syntaxique.

Amusant on m'a appris cette règle de conception hideuse avec un autre langage que java.. et avant que java existe même (qui a dit oh le vieux ? )

Explication de la dites règle que tu semble méconnaitre:

Si tu accèdes directement a un attribut d'une classe et que demain pour une raison XY ou Z tu as une nouvelle contrainte a vérifiée avant d'accéder a l'objet en lecture et ou en écriture tu te retrouves a réécrire tout tes accès pour utiliser le couple infernal setter/getter, pas top au niveau de la maintenance de ton code tu en conviendras..
Le pire que tu pourrais faire étant de laisser ton champ public et de juste ajouter les getter/setter en sus, résultat si tu oublies de changer un accès ou si quelqu'un décide d'accéder directement a l'attribut tu as un gros problème..

Bulbo

[yolepro]

Et dans le cas d'une implémentation comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
public String prenom;
 
public String getPrenom(){
  return prenom;
}
 
public void setPrenom(String prenom) {
  this.prenom = prenom;
}

il faudrait choisir quoi avec la solution 1 ?

Autant enlever la complexité des getter setter grâce à des annotations c'est une bonne idée (cela respecte tout de même les spec des javabean), autant modifier la manière d'appeler ces accesseurs, ca déforme énormenent la manière de penser et cela devient vraiment confus.