Discussion :

[dingoth]

Non, pour la sécurité, seule une console SSH est à disposition. Oui, même pour le serveur de développement et celui de test, choix imposé par le client.

Ceci dit, mon équipe et moi ne sommes pas fous non plus. Actuellement, il est vrai que seules les retouches sont faites avec vi. D'habitude, on contourne la décision du client et on développe sur nos propres machines, avant de faire un scp des sources. Mais en terme de temps, on passe plus de temps devant le terminal que devant Eclipse, puisqu'il faut tout faire à la main (recompilation, correction d'erreurs de syntaxe lors de modifs à la main, etc.)

[bgrand]

Pour mais un peu plus configurable.
Sinon comment dire "je veux juste un setteur" "le setteur est protected"

Pourquoi ne pas ajouter des annotations prisent en compte au javac

Code :

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

1
2
3
4
5
6
7
8
 
public class Person {
 @access readWrite protected
 public String forename;
 
 @access read public
 public int age;
}

Je vais dans le même sens que Sami, je suis pour à condition d'avoir une notion de permission. Les annotations me semblent tout à fait appropriées.

[adiGuba]

Les annotations me semblent tout à fait appropriées.

Sauf que les annotations n'ont aucun impact sur le code source généré, mais se contente d'ajouter des informations...

a++

[bgrand]

Sauf que les annotations n'ont aucun impact sur le code source généré, mais se contente d'ajouter des informations...

a++

Informations qui sont prisent en compte par la JVM pour modifier le comportement du programme. Je ne suis pas spécialiste des annotations, je ne sais pas trop dans quelle mesure c'est possible de les utiliser dans ce cas là...

[adiGuba]

Je ne suis pas spécialiste des annotations, je ne sais pas trop dans quelle mesure c'est possible de les utiliser dans ce cas là...

Disons que dans les spécifications des annotations il est indiqué que les annotations ne peuvent pas modifier le code généré pour le fichier dans lequel elle se trouve.

Grosso modo les annotations peuvent être utilisé par le compilateur pour générer des warnings/erreurs mais pas pour générer un code différent...

Donc dans l'état actuel une annotation ne pourra pas générer le code des getter/setter (bien sûr les spec des annotations pourraient changer)


a++

[bgrand]

Merci pour l'explication ! Donc en effet, les annotations ne peuvent pas (en l'état actuel) générer le code des getters/setters, éventuellement permettre à la JVM d'y limiter l'accès pendant l'exécution, ou alors comme tu le suggères, modifier la spec des annotations... Quoi qu'il en soit, il y a encore des discussions nécessaires avant d'adopter cette fameuse proposition 12 !

[Tarul]

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.

Je rajouterai à ta proposition un attribut name dans l'annotation qui permettrait de fixer le nom visible de la propriété de l'extérieur tout en permettant le changement du nom de la variable rattaché à la proriété.

[tralloc]

Moi je suis clairement pour

Mais comme le disent pas mal de gens, avoir une méthode un peu comme en C# pour faire des contrôles, ajouter des actions...

Sinon : à quoi ça sert ? On pourrait bien travailler directement avec des variables classiques.

[bulbo]

Moi je suis clairement pour

Mais comme le disent pas mal de gens, avoir une méthode un peu comme en C# pour faire des contrôles, ajouter des actions...

Sinon : à quoi ça sert ? On pourrait bien travailler directement avec des variables classiques.

CQFD: une proposition qui vient affaiblir une des règles de bases de l'encapsulation ne peut pas être bonne..

J'ai l'impression qu'il y a deux sortes de langages, ceux qui sont permissifs en diable pour faire plaisir au développeur lambda qui ne passe que par des raccourcis dangereux ou bizarre.. et ceux qui tire le développeur vers le haut en le forçant a suivre des règles de programmation propre et a se soucier du design.

Java fait parti de la deuxième parti et plus que le fait du "compile once, run everywhere" je pense que c'est ça qui a plu a la grande communauté java d'aujourd'hui

Pour prendre un langage 'a la mode' qui a été cité, qui se verrait développer un serveur d'application en python ? Ou une grosse librairie graphique genre JFreeChart ?

La force de java c'est que c'est un langage propre, les sucres syntaxiques qui n'apporte rien de nouveau et complexifie la lecture ne sont a mon avis que des pas en arrière et surement pas un progrès.

On gagne du temps avec une conception claire et un design étudié, pas en écrivant 3 caractères des moins de temps en temps.. sinon la solution ne serait pas des sucres syntaxiques mais des cours de dactylo..

Bulbo

[_Raynor_]

Pour UNIQUEMENT SI :
- on peut spécifier les "autorisations" d'accès à la propriété est read only, write only ou bien read&write (on fabrique donc des attributs publics mais à accès restreint

Cela dit, on fait déjà très bien cela avec des plusieurs Getters et Setters persos.

[gokud-o-matic]

CQFD: une proposition qui vient affaiblir une des règles de bases de l'encapsulation ne peut pas être bonne..

J'ai l'impression qu'il y a deux sortes de langages, ceux qui sont permissifs en diable pour faire plaisir au développeur lambda qui ne passe que par des raccourcis dangereux ou bizarre.. et ceux qui tire le développeur vers le haut en le forçant a suivre des règles de programmation propre et a se soucier du design.

Java fait parti de la deuxième parti et plus que le fait du "compile once, run everywhere" je pense que c'est ça qui a plu a la grande communauté java d'aujourd'hui

Pour prendre un langage 'a la mode' qui a été cité, qui se verrait développer un serveur d'application en python ? Ou une grosse librairie graphique genre JFreeChart ?

La force de java c'est que c'est un langage propre, les sucres syntaxiques qui n'apporte rien de nouveau et complexifie la lecture ne sont a mon avis que des pas en arrière et surement pas un progrès.

On gagne du temps avec une conception claire et un design étudié, pas en écrivant 3 caractères des moins de temps en temps.. sinon la solution ne serait pas des sucres syntaxiques mais des cours de dactylo..

Bulbo

desole, ce n'est pas 3 characteres qu'on essaye d'enlever mais 30 a chaque champ. 50 km de lignes de codes en declaration et initialisation n'est pas ce qui attire les gens, et J2EE en est la preuve.
Et puis un language qui n'evolue pas est comme mort.

[bulbo]

desole, ce n'est pas 3 characteres qu'on essaye d'enlever mais 30 a chaque champ. 50 km de lignes de codes en declaration et initialisation n'est pas ce qui attire les gens, et J2EE en est la preuve.
Et puis un language qui n'evolue pas est comme mort.

Marrant ça .. le perl ne change pas depuis longtemps et pourtant .. le C est resté identique même les biblio standards bouge pas et pourtant c'est encore super utilisé .. le C++ change mais est en train de mourir.

Ce qu'on est en train d'enlever c'est un garde fou qui faisait que les gens n'accédait pas à des champs public mais utilisait des accesseurs, si demain cette habitude disparait certains vont avoir de très mauvaises surprises quand il y aura soudainement un besoin en getter ou setter et que ça n'aura pas été fait.

Gain en fonctionnalité pour le développeur = 0
Gain en écriture seulement
Introduction d'un risque plus grand que le débutant utilise directement un champ public (quasi identique qu'une property et plus rapide d'accès)

Bulbo

[gokud-o-matic]

Marrant ça .. le perl ne change pas depuis longtemps et pourtant .. le C est resté identique même les biblio standards bouge pas et pourtant c'est encore super utilisé .. le C++ change mais est en train de mourir.

le perl a de moins en moins d'adeptes justement parce qu'il n'évolue plus. C'est sur que c'est un langage totalement éprouvé, mais ça risque de ne pas suffire pour ramener des gens. Pour le C, on n'a simplement toujours pas trouvé de vraie alternative pour les systèmes embarqués. Et puis Linux contient beaucoup de C. Le C++ meurt parce qu'il y a justement des alternatives. On peut donc dire que le C ne reste que grâce à son monopole.

Ce qu'on est en train d'enlever c'est un garde fou qui faisait que les gens n'accédait pas à des champs public mais utilisait des accesseurs, si demain cette habitude disparait certains vont avoir de très mauvaises surprises quand il y aura soudainement un besoin en getter ou setter et que ça n'aura pas été fait.

Gain en fonctionnalité pour le développeur = 0
Gain en écriture seulement

Gain en lisibilité, c'est aussi très important. Comme je disais, très peu de gens aiment se farcir des pages entières de code qui n'est pas du code métier. Avec 5 champs que je veux rendre publique, je remplis déjà un écran (heureusement qu'il y a le code folding). Et puis, à nouveau pour la lisibilité, je vois un énorme gain si je peux transformer par exemple

Code :

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

personne.setEtiquette( personne.getNom() + " " + personne.getPrenom() );

en

Code :

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

personne.etiquette = personne.nom + " " + personne.prenom;

Pour lire, ça peut aider vachement.

Introduction d'un risque plus grand que le débutant utilise directement un champ public (quasi identique qu'une property et plus rapide d'accès)

Bulbo

je ne comprends pas ta phrase. Qu'est ce que tu entends par champ public et property dans ce contexte?

[bulbo]

Un champs public est une variable de classe déclarée public, l'accès se fait de la même manière que pour une property dans la proposition pour le JDK7

Premier problème que je vois: lisibilité pour savoir si on a affaire a une property ou a un champs public (chose fortement déconseillée) il faut aller voir la déclaration de la variable .. moins lisible que la différence entre un appel de méthode (avec () ) et accès a un champs

Deuxième problème: pour un débutant c'est la même chose au mot clé property près qu'une déclaration de champs public (je répète caca pas bien) donc pourquoi se prendre la tête avec un mot clé en plus si ça revient au même ?
Déjà aujourd'hui on a du mal a leur faire comprendre parfois l'intérêt des get/set, ça ne va pas aider a les convaincre..

J'espère que c'est plus clair comme ça ..

Bulbo

[Uther]

Un champs public est une variable de classe déclarée public, l'accès se fait de la même manière que pour une property dans la proposition pour le JDK7

Premier problème que je vois: lisibilité pour savoir si on a affaire a une property ou a un champs public (chose fortement déconseillée) il faut aller voir la déclaration de la variable .. moins lisible que la différence entre un appel de méthode (avec () ) et accès a un champs

La je suis d'accord, c'est le défaut de la propsition 1 mais il y en a 3.

Deuxième problème: pour un débutant c'est la même chose au mot clé property près qu'une déclaration de champs public (je répète caca pas bien) donc pourquoi se prendre la tête avec un mot clé en plus si ça revient au même ?
Déjà aujourd'hui on a du mal a leur faire comprendre parfois l'intérêt des get/set, ça ne va pas aider a les convaincre..

Là je ne suis pas d'accord. Quand j'étais débutant, je n'utilisais pas les getter/setter justement parceque je ne comprenais pas l'interêt de me taper deux fonctions pour finalement arriver au même résultat.
Si on m'avait expliqué qu'il falait juste ajouter un petit mot clé pour que l'accès puisse être correctement encapsulé, je ne me serait pas posé de question.

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