Discussion :

[vbrabant]

Accès aisé aux propriétés

Proposition 1 :
En utilisation le point comme séparateur

Code :

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

1
2
3
4
5
6
7
8
 
public class Person {
 public property String forename;
 public property int age;
}
Person p = new Person();
p.forename = "Stephen";   // calls setter
String str = p.forename;  // calls getter

Proposition 2 :
En utilisant => comme séparateur

Code :

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

1
2
3
4
5
6
7
8
 
public class Person {
 public property String forename;
 public property int age;
}
Person p = new Person();
p=>forename = "Stephen";   // calls setter
String str = p=>forename;  // calls getter

Proposition 3 :
En utilisant # comme séparateur

Code :

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

1
2
3
4
5
6
7
8
 
public class Person {
 public property String forename;
 public property int age;
}
Person p = new Person();
p#forename = "Stephen";   // calls setter
String str = p#forename;  // calls getter

[metalpetsFR]

Et pourquoi pas appelé la méthode setAge() définit implicitement?

[lunatix]

clairement contre, tant que c'est ajouter un nouveau mot clé, ou pire les => ou # en accesseurs.

(et puis bon, comment on fait avec les annotations qui se placent sur les méthodes apres @Required de spring, les annotation jpa etc...)

modifier le langage pour remplacer quelque chose qui se fait en 3 secondes avec un ide, je trouve ca inutile

[austin P.]

contre

n'apporte pas grand chose et je ne trouve pas la lecture plus clair

[OButterlin]

Pour la 1, si on peut continuer à utiliser les getter/setter

[heid]

pour la 1 (existe en c# et est très pratique).

[BakaOnigiri]

si on fait çà, en plus des getter/setter automatique, quel serais le véritable avantage sur un membre public ??

[bulbo]

Contre,

Encore une fois un sucre syntaxique pas très utile (on économise 6 caractères, quelle fête) par contre on perd beaucoup en lisibilité.. sans compter les gens qui avaient déjà du mal a faire des set/get au lieu d'un champ public, si l'appel est le même elles vont se donner encore moins de mal pour faire les choses proprement.

Bulbo

[elitost]

Aucune proposition vraiment satisfaisante.

[nicorama]

Rien d'assez interessant pour mériter de chambouler ce qui a été fait avant. Comparé aux avancées vraiment pratiques du JDK5, ca fera trop de changement peu utile qui masquera les réelles avancées, si il y en a.

[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

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

[laurent_m]

Contre en tout points
Comme bien des gens ont dit,
Cela rendrait la lecture du code assez hasardeuse à mon avis.
De plus, si on prend l'approche éducative des getters/setters et attributs de classes privés, ceci instituerait à mon sens un risque accru d,utilisation de mauvaises pratiques de conception....

Ce n'est que mon avis, je ne sais à quel point il est juste

[g_rare]

100% CONTRE