Discussion :

[gokud-o-matic]

Il était temps. Les propriétés font quand même partie du principe de l'encapsulation.

J'ai une nette préférence cette écriture :

Code :

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

   [public, private ou protected]property Type nomObjet getter getNomObjet() [ou fNomObjet] setter setNomObjet() [ou fNomObjet];

C'est clair et précis.


nota, le terme getter peut etre remplacé par read et setter par write.

et pour les proprietes de listes, comment tu fais? exemple, j'ai un Vector<String> que je veux mettre en propriete et que je veux y acceder comme dans un String[]. comment faire avec ta notation?
avec ta notation, j'imagine que ce serait, pour ne pas empecher les vrais arrays, comme ceci:

Code :

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

property Type[<Generic>] nomObjet[] [getter nomObjet|nomMethod] [setter nomObjet|nomMethod]

exemple

Code :

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

1
2
3
4
5
6
//declaration
property String nom[] getter getNom setter setNom
 
//usage
String monNom=obj.nom[i];
obj.nom[j]="autre chose";

j'enleve les () parce qu'elles ne font qu'induire en erreur, et j'ai mis les getter et setter en option pour definir les droits de lecture/ecriture. j'enleve aussi les private|public|... parce que une propriete devrait toujours etre publique, sinon autant acceder directement au field. Et puis, j'ai mis les [] apres le nomObjet pour signaler que c'est une propriete liste. S'il s'agissait d'une propriete simple d'un objet array statique, ce serait plutot un

Code :

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

property Type[] nomObjet...

exemple

Code :

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

property int[] liste getter...

j'ai aussi mis en option les generiques pour les classes qui l'utiliseraient. Au pire, les generiques pourraient etre une alternative temporaire aux proprietes listes que je propose. exemple:

Code :

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

property Vector<String> maListe getter...

Malheureusement, ca interdit un acces rapide aux valeurs.

Mais sinon, c'est effectivement une maniere elegante avec 3 mots clefs.

[dams77]

Pour ma part je suis contre. Je veux garde un contrôle total.

Exemple je ne veux que des getters et aucune setter. Je veux effectuer des contrôles sur les paramètres ( setter ). Ici je ne peux pas.

[gokud-o-matic]

Pour ma part je suis contre. Je veux garde un contrôle total.

Exemple je ne veux que des getters et aucune setter. Je veux effectuer des contrôles sur les paramètres ( setter ). Ici je ne peux pas.

Lis donc les derniers posts, ils intègrent cette possibilité

[jproto]

En fait, je ne voyais pas les choses comme ça.
Pour moi, cette notation doit juste permettre de ne pas avoir à écrire des getter/setter qui pour le moment n’ont aucune valeur ajoutée, tout en gardant la possibilité d’ajouter des contrôles plus tard en créant ses propres méthodes.

Les getter/setter seraient générés directement par le compilateur selon la condition suivante :
Il n’existe encore aucune des méthodes possédant la signature que le compilateur aurait exploité.

Dans le cas contraire, le compilateur ne fait rien.

Ainsi, si rien n’est déclaré explicitement, le compilateur fait son œuvre.
Dès que l’une de ces méthodes est créé, le compilateur nous fait confiance et ne génère plus rien lui-même. Nous gardons ainsi la possibilité de ne créer que des getter (par exemple).
A noter qu’à partir du moment où l’on a explicitement déclaré l’une de ces méthodes, la nouvelle notation n’a en fait plus lieu d’être.

Quoi qu’il en soit, cela permet de gagner du temps et d’alléger le code vis-à-vis des 38 variables d’instances de ta classe sur 42 pour lesquelles tu n’as aucun contrôle à réaliser (au moins pour le moment).

Chris.

[gokud-o-matic]

En fait, je ne voyais pas les choses comme ça.
Pour moi, cette notation doit juste permettre de ne pas avoir à écrire des getter/setter qui pour le moment n’ont aucune valeur ajoutée, tout en gardant la possibilité d’ajouter des contrôles plus tard en créant ses propres méthodes.

Les getter/setter seraient générés directement par le compilateur selon la condition suivante :
Il n’existe encore aucune des méthodes possédant la signature que le compilateur aurait exploité.

Dans le cas contraire, le compilateur ne fait rien.

Ainsi, si rien n’est déclaré explicitement, le compilateur fait son œuvre.
Dès que l’une de ces méthodes est créé, le compilateur nous fait confiance et ne génère plus rien lui-même. Nous gardons ainsi la possibilité de ne créer que des getter (par exemple).
A noter qu’à partir du moment où l’on a explicitement déclaré l’une de ces méthodes, la nouvelle notation n’a en fait plus lieu d’être.

Quoi qu’il en soit, cela permet de gagner du temps et d’alléger le code vis-à-vis des 38 variables d’instances de ta classe sur 42 pour lesquelles tu n’as aucun contrôle à réaliser (au moins pour le moment).

Chris.

c'est tout de même une vision très réductrice des propriétés. Et lorsqu'on voudra implémenter des propriétés de style tableau (parce que oui, c'est très utile et c'est inexistant sous java), il vaudra mieux avoir bien pensé les bases des propriétés pour une évolution possible.

[jproto]

c'est tout de même une vision très réductrice des propriétés. Et lorsqu'on voudra implémenter des propriétés de style tableau (parce que oui, c'est très utile et c'est inexistant sous java), il vaudra mieux avoir bien pensé les bases des propriétés pour une évolution possible.

But: supprimer le fait d'écrire des setters et getters

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;
}

Je te l’accorde, et je trouve effectivement intéressant d’étendre la réflexion.
Cependant, pour répondre à la question première, je ne suis pas convaincu d’avoir vraiment répondu à côté. Je n’ai initialement perçu aucune allusion à une manipulation de type tableau, ni à un souhait de l’aborder (au moins pour répondre au sondage POUR / CONTRE).

En revanche, maintenant que le sujet a été levé, cette perspective est intéressante, mais tel que tu le mentionnes toi-même, il serait dommage que cela soit au détriment des performances.

Chris

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

[ITCsoft54]

Je ne vois pas vraiment l'intérêt de la chose.

J'ai voté contre.

On fait la même chose avec un :

Code :

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

1
2
 
Public Type_Variable  var;

Mettre des "Properties", n'apporte rien. je préfére gardé mes setter et getter, avec au moins on sais où on vas !

si c'est pour rajouter des @set @get et toutes les horreurs du même style pour récupérer les fonctionnalités du getter / setter, alors pourquoi pas tous simplement garder le setter et le getter ?

[jproto]

En fait, non. Il s’agit du principe même d’encapsulation.
La proposition propose de gagner du temps en générant des setter/getter par défaut sur les variables pour lesquelles on lui demande. Cela n’a rien à voir avec le fait de les rendre publique, car nous gardons la possibilité de les définir.
Si tes variables sont publiques, tu peux dire adieu à l’idée de contrôler leur accès dans le futur.

[yann2]

Bonsoir

J'ai voté (y a longtemps) Contre... ça me rappelle quand j'ai appris la prog avec ... VB6 . Mais, c'est bizarre, en le voyant noir sur bleu, l'exemple de gokud-o-matic je me dis que finalement l'idée n'est pas si mauvaise et existe depuis longtemps pour d'autres langages.

J'imagine que je ne peux changer mon vote. Pas grave en même temps ça ne va pas changer la face du monde et ça ne va pas m'empêcher de dormir.

Par contre je me pose des questions sur les conséquences de l'ajout d'un mot clé qui se nommerait.... property ! Déjà qu'il y en a qu'on du mal à passer à Java 5...

Bref ici, on nous explique pourquoi on ne peut utiliser les opérateurs < et > en lieu et place de la méthode compareTo, alors j'aimerai bien savoir comment on peut introduire un nouveau mot clé "property"

Il va falloir utiliser le -ep (enable property ) à la compilation ?

bonne nuit

yann

[Uther]

Le problème n'est pas nouveau et il devrait être géré comme pour les asserts(en java 1.4) ou les enum(en java 1.5):
Par défaut les programmes qui utilisent le mot property seraient cassés, pour les faire marcher sans modification on porra utiliser le paramètre "-source 1.6"

[jakkk]

C'est une bonne idée. Cependant avec juste le mot property, on ne peut pas réellement controler séparément les getter et les setter, on ne connaît pas la visibilité de la variable.

Je rejoins l'idée de Tarul (avec ou sans les annotations)

Code :

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

1
2
3
4
5
@encapsulate(private set, private get)
private Class var;
 
@encapsulate(public set, public get)
protected Class var;

mais c'est vrai qu'écrire

Code :

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

1
2
3
private Class var
public void setVar(Class var){this.var=var}
public Class getVar(){return var}

C'est pas la mer à boire, surtout que le Netbeans ou Eclipse le fait automatiquement ...

[kisame]

bha je ne vois pas en quoi ça pourrait briser l'encapsulation, quand on fait un get() ou un set() on ne brise pas l'encapsulation. Et ça n'est en rien comparable à une transformation en public. Sauf à l'écriture. Par contre le risque est peut-être là.
Ce n'est pas un accès direct, c'est un appel à une méthode générée (si c'est bien copié sur le truc du c#). En lisant le code on aura du mal à voir la différence.

Ensuite,

Si on veut faire un getter et/ou setter bien specifique (ce n'est plus un bean pur on est d'accord), il sera mélangé dans un code où on aura du getter/setter généré et du getter/setter fait à la main. Donc au niveau de

notre code on fera pour la déclaration

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 user{
 Date naissance;  (<--getter setter specifique)
 String property  nom;        (<-- getter setter généré)
 
 getAge()
 {
    // calcul de l'age
 }
 
 setAge(int age)  (<--  oui l'exemple est moisi mais j'espère que vous comprenez)
{
  // 
}
}

Pour le traitement.

Code :

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

1
2
User user =...;
system.out.println(user.nom+ " a aujourd'hui " + user.getAge() + " ans");

Je trouve que ça fait brouillon. Surtout que les EDI génèrent super bien tout ça. Contre.

[jproto]

bha je ne vois pas en quoi ça pourrait briser l'encapsulation, quand on fait un get() ou un set() on ne brise pas l'encapsulation.

...

En fait, je répondais à ceci :

Je ne vois pas vraiment l'intérêt de la chose.

J'ai voté contre.

On fait la même chose avec un :

Code :

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

1
2
 
Public Type_Variable  var;

Mettre des "Properties", n'apporte rien. je préfére gardé mes setter et getter, avec au moins on sais où on vas !

si c'est pour rajouter des @set @get et toutes les horreurs du même style pour récupérer les fonctionnalités du getter / setter, alors pourquoi pas tous simplement garder le setter et le getter ?

Cela dit, autant nous semblons d'accord sur le principe d'encapsulation, autant nous le sommes moins sur l'aspect "brouillon".

Pour ma part, cela ne me choque pas. En fait, c'est une chose que nous pouvons côtoyer régulièrement lorsque l'on songe aux constructeurs par défaut qui sont générés automatiquement par le compilateur si aucun constructeur n'est écris manuellement pour une classe.

Chris.

[Bollagain]

Je vote Contre ...

J'ai trouvé ca tout a fait super au debut, tant ca me gon... de devoir me taper la redaction de tout ces assesseurs... mais cela pose quand même pas mal de soucis.

Comme on peut la constater a la lecture de ce thread, cette seul proposition ne peut pas suffire... puisqu'il est nécessaire que l'on puisse contrôler la porté de la propriété et de ses deux assesseurs. Malheureusement, aucune proposition faites ici ne m'a convaincu et je tire de ce constat l'idée qu'il n'y a sans doute pas de façon simple, évidente et indiscutable.

En conséquence, cela veut dire que la vrai façon simple, claire et indiscutable de définir une propriété passe encore par la définition manuelle les assesseur.

Ainsi, entre :

Code :

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

1
2
3
4
 
 @access read public
 @access write protected
 public String forename;

et

Code :

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

1
2
3
4
5
 
 public String forename = null ;
 
 public String getForename() { return forename ;}
 public void setForename(String s) { forename = s ;}

Je préférè encore la seconde.

Cette modification ne vise qu'au confort et n'apporte rien en terme de qualité logiciel. Par principe, seul ce dernier critère est important dans le cadre de l'évolution du langage. Les aspect "Confort" peuvent, bien mieux, être addréssé par les EDI, les fonctionnalité avancé d'Eclipse en sont une trés bonne illustration.

[euskadi_21]

Je suis totalement contre car à la relecture d'un code on ne pourra plus savoir au premier coup oeil si on accède à une proriété public ou à un getter(/setter) auto généré. A partir de ce moment là, maintenir du code imposant (plusieurs milliers des ligne de code) va vite devenir difficile pour celui qui n'est pas à l'origine de la définition de la classe. Et prire encore, s'il une propriété devait impérativement être au plus protected et que le développeur l'a mise public, la détection de ce bug va être très délicate.

Encore une fois, ça ne sert strictement à rien étant donné que les IDE comme NetBean ou Eclispe font ça très bien. Ca ne ferait que rajouter de la confusion.

un petit exemple :

Code :

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

1
2
3
4
5
public class A {
 
 public String propB;
 public property String propA;
}

dans une autre classe :

Code :

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

1
2
3
4
5
6
7
8
9
public class B {
  private A a;
  public void methodeB(...) {
  ....
  a.propB = "C";
  .....
  a.propA = "D";
  }
}