Discussion :

[lunatix]

bon, j'avais voté contre, mais a la réflexion (et après avoir lu groovy in action ) je voterai pour la proposition 1 maintenant.

c'est vrai que les palanquées de geters/seter c'est finalement du bloat inutile dans les objets.

et puis ca va bien avec mon habitude en JPA de préférer les annotations sur les attributs, plutôt que sur les méthodes.

[Bollagain]

Vadé retro proposition 1 ... et, quoique moins violemment, contre les deux autres propositions

Au dela du fait que j'ai voté contre à la proposition 12, cette proposition 13 ajoute deux nouveaux opérateurs qui ne servent pas vraiment.

Plus généralement, je trouve que l'apprentissage du langage Java est assez complexe pour un 'nouvel' entrant.... ce qui est normal. Au dela des éléments syntaxiques propres au langage, le programmeur en apprentissage doit aussi apprendre les différentes API, innombrables et souvant incontournable.

Inutile donc d'ajouter, en plus, de la complexité au fondamentaux du langage si ce n'est pas pour ajouter des fonctionnalités non encore existantes.

[revever]

Contre. Imaginons une classe 'Machine' (l'état ne peut pas etre écrit; le password ne peut pas etre lu)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public class Machine{
     private int state;
     private byte[] password;
     public property String name;
     public property Date date;
 
     public int getState(){
          return this.state;
     }
 
     public void setPassword(byte[] pwd){
          this.password=pwd;
     }
}

Au moment d'utilisation, je trouve c'est fou de changer entre 'getter/setter' et 'property' de temps en temps.

Code :

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

1
2
3
4
5
 
machine.getState();
machine#name="AK47";
machine.setPassword(null);
println(machine#date);

quand y a beaucoup de classe comme ça, ça sera bordel de getter/setter/property!!!

[Rizzen]

Contre je trouve l'idée inutile et risque de posé des problème de lisibilité et on va se perdre entre attribut et méthode get/set

[Invité1]

J'ai voté contre cette proposition.

En fait, je ne vois pas bien l'intérêt. D'autant plus que l'utilisation des préfixes "get" et "set" pour les accesseurs et commutateurs n'est pas du tout obligatoire (j'ai l'impression que ça tend à disparaître d'ailleurs, ce qui n'est pas une mauvaise chose). Ce qui peut donner :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public class Person {
   private String forename;
   private int age;
   public void forename(String forename) { this.forename = forename ; }
   public String forename() { return this.forename ; }
   public void age(int age) { this.age = age ; }
   public int age() { return this.age ; }
}
Person p = new Person();
p.forename("Stephen");   // calls explicit setter
String str = p.forename();  // calls explicit getter

Ce qui est déjà très lisible. Ça fait exactement ce que l'on veut que ça fasse. Quel est l'intérêt d'ajouter ce nouveau mécanisme de "property" ?!

En plus, dans certains cas, on va préférer renvoyer une copie de l'objet privé plutôt que l'objet lui-même. Dans d'autres cas, on va vérifier si telle valeur remplit telle condition avant de l'assigner à la donnée membre.

Enfin bref, je trouve que cette proposition 13 n'apporte rien (voire empêche de faire certaines choses). (Mais à choisir, je choisirait le '#'.)

PS: La proposition d'azalsup pourrait être intéressante

[zegreg]

autant j'étais pour le "property" comme racoursis... mais l'accès à un attr doit rester get et set, ce serait tout bonnement remettre en cause la norme javabean. Que deviendraient tous les frameworks se basant sur des getters setters recherchés par introspection ???

[zegreg]

la proposition 1 est tout bonnement n'importe quoi... autant retirer le property et c'est déjà faisable ...

c'est quoi l'avantage d'avoir le mot clé property dans ce cas... y a qu'à le retirer et mettre ses attr en public

[dingoth]

En fait, je ne vois pas bien l'intérêt. D'autant plus que l'utilisation des préfixes "get" et "set" pour les accesseurs et commutateurs n'est pas du tout obligatoire (j'ai l'impression que ça tend à disparaître d'ailleurs, ce qui n'est pas une mauvaise chose).

Je ne suis pas d'accord du tout : s'il y a bien quelque chose d'illisible, c'est la méthode que tu décris. Lorsqu'on lit du code java bien pensé, généralement cela se fait de la forme sujet.verbeComplément(valeurs) (avec le complément facultatif). Et le verbe est la description typique d'une action (d'ailleurs au pictionnary, le mot "action" recouvre l'ensemble des verbes). Que ce soient des méthodes métier ou des méthodes d'accesseurs, il faut garder le verbe. Qu'il soit écrit implicitement dans le code pour l'accession aux propriétés ou pas, il faut garder le verbe. C'est limite si ce n'est pas la base de la POO entière.

D'un point de vue personnel, seuls le = et le set attribuent une nouvelle valeur. Des valeurs avec des verbes explicites peuvent le faire (genre un update généralisé), mais écrire monObjet.maPropriété(maNouvellePropriété) est des plus dérangeants. Déjà que certains programmeurs ont des difficultés avec des noms de méthodes identiques, ta solution ne ferait qu'accentuer ce problème.

Je ne dis pas que cela n'a pas son utilité (dans un wrapper de GBC en Swing par exemple, je dis pas non), mais c'est à limiter et à cadrer de manière précise.

[trolldom]

Pour 1
cela permet de faire évoluer une structure de donnée vers une class sans changer le code client.

Code :

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

1
2
3
4
 
Class Person {
  public property String name;
}

peut évoluer vers

Code :

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

1
2
3
4
5
6
7
 
Class Person {
  public property String name;
  public String SetName(String value){
    //ma logique qui tue
  }
}

[Petrus]

Pas séduit pour ma part.

Les appels implicites à des accesseurs et/ou mutateurs dégradent la lisibilité du code je trouve et risquent d'introduire des bugs sémantiques pour une simplicité syntaxique qui reste à prouver !

[vanacid]

Voici une syntaxe qui a plus de sens, directement empruntée de C# par contre.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 
public class ObjTmp
{
 
private String a;
private String b;
private String c;
 
public readonly property a()
{
    String get()
    {
        return a;
    }
}
 
public writeonly property b()
{
    void set(String value)
    {
         if(valider(b))
         {
             b = value;
         }
         else
         {
             // ... gérer l'erreur
         }
    }
}
 
public property c()
{
    String get()
    {
        return c;
    }
 
    void set(String value)
    {
         if(valider(value))
         {
             c = value;
         }
         else
         {
             // ... gérer l'erreur
         }
    }
}
 
}
 
// dans une méthode d'un autre objet
ObjTmp tmp = new ObjTmp();
tmp.a = "5";      // Erreur
String d = tmp.a; // Ok
String e = tmp.b  // Erreur
tmp.b = "abc"     // Ok
tmp.c = "abc"     // Ok
String f = tmp.c  // Ok

[adiGuba]

Voici une syntaxe qui a plus de sens, directement empruntée de C# par contre.

Heu... Ton code me semble encore plus long d'un simple attribut avec des get/set standard !

[vanacid]

Heu... Ton code me semble encore plus long d'un simple attribut avec des get/set standard !

Code :

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

1
2
3
4
5
6
7
8
9
10
 
ObjTmp tmp = new ObjTmp();
tmp.c = "abc";
String d = tmp.c;
 
versus
 
ObjTmp tmp = new ObjTmp();
tmp.setC("abc");
String d = tmp.getC();

J'aime bien le résultat lors de l'utilisation de la classe

Voici l'ancien code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
public class ObjTmp
{
 
private String a;
private String b;
private String c;
 
public String getA()
{
    return a;
}
 
public void setB(String value)
{
   if(valider(value))
   {
      b = value;
   }
   else
   {
      // ... gérer l'erreur
   }
}
 
public String getC()
{
    return c;
}
 
public void setC(String value)
{
   if(valider(value))
   {
      c = value;
   }
   else
   {
      // ... gérer l'erreur
   }
}
 
}
 
// dans une méthode d'un autre objet
ObjTmp tmp = new ObjTmp();
String e = tmp.getA() 
tmp.setB("5");
tmp.setC("abc")
String f = tmp.getC()

C'est vraiment plus court ?

En plus avec ma méthodes, les get et les set sont inévitablement groupés.

Et le code peut facilement être généré par l'IDE.

[adiGuba]

C'est vraiment plus court ?

Ben déjà tu n'a pas de répétition entre l'attribut et la property... et je ne suis pas trop pour utiliser le . pour appeler un accesseur implicite, car après on ne sait plus trop ce que fait le code :

Code :

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

a.b;

Appel de méthode ou accès à un champs ?

a++

[vanacid]

Ben déjà tu n'a pas de répétition entre l'attribut et la property... et je ne suis pas trop pour utiliser le . pour appeler un accesseur implicite, car après on ne sait plus trop ce que fait le code :

Code :

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

a.b;

Appel de méthode ou accès à un champs ?

a++

C'est sur que c'est un peu difficile et que ça se rapproche des "operator overloading" de C++. Sauf que ça te permet de faire une validation avant d'affecter ta propriété (comme avec une méthode) sans avoir à faire l'appel de la méthode. Tu peux utiliser les assertions ou (de manière plus laide) lancer une RuntimeException dans le cas où l'affectation est invalide.

Je trouve que c'est une très bonne syntaxe qui s'utilise en .NET qui se tranfèrerait très bien en Java.

[fabszn]

Hello,

Je suis contre les trois propositions.

Ca n'apporte rien, sauf de la confusion. Le gain est inexistant par rapport aux outils fournis par les ides.

[DranDane]

Franchement a la vue des modifications proposées ca converge quand même énormément...

Sinon je partage ton apréhention par rapport à l'IDE. Pour ma part mieux vaux rien du tout que un autre caractère que le '.'

Le problème de différentiation est le même que celui qui permet de différentier une méthode de la méthode constructeur, d'une variable de class à une variable local, etc... les développeurs que nous sommes trouverons bien une méthode. Majuscules, minuscules, underscore, etc... Faites travailler votre imagination

Le . est donc suffisant pour moi. D'autant plus qu'il veut bien dire ce qu'il veut dire. Pourquoi utiliser un autre séparateur alors que finalement derrière la propriété se cache une méthode.

[ratamovic]

Le . est largement suffisant! Principe d'encaspulation: on n'a pas à savoir ce qui se passe en interne! D'autant que 90% des getters/setters ne reviennent qu'à un accès direct à la variable. Et pour ce qui est des variables publiques, de tte façon, ebn dehors de "structures", il ne faudrait jamais les utiliser.

C'est utile dans le cadre de variables protected que beaucoup de programmeurs ne veulent pas encapsuler pour cause de lourdeur (avec les property on peut facilement passer d'une simple variable membre à des getter/setters sans modifications dans le reste du code).

Le système des property est utilisé depuis la version initiale de Delphi vieille de 15ans et marche nickel! Le code est souvent plus lisible et simple qu'avec des get() set() (àl'exception des begin end qui ne sont pas appréciés par tout le monde )!

[tchize_]

Contre la proposition 1: on aboli la distinction méthode / variable, l'accès à une variable peut subitement déclencher une exception.

Contre la proposition 2: moins lisible (=> est très proche visuellement parlant de <=, qui est un comparateur)

Contre la proposition 3: les # nécessite de faire alt-gr 3 sur les claviers belges, soit une certaine gymnastique du poignet, encore une fois, j'irais vite à tapper get-ctrl-space (se fait entièrement de la main gauche gtd'un mouvement continu avec seulement 3 doigts impliqués) pour choisir ma méthode que de tapper altgr-3-ctrl-space ( nécessite deux mains, quatre doigt et au moins 3 fois plus de distance parcoure sur le clavier)

[tchize_]

Le # me semble une très mauvaise idée au contraire.

on va surtout voir fleurir partout dans le code de c#ceci, c#cela, c#inadmissible!