JDK 7: Proposition 13 : Accès aisé aux propriétés [Débat]

**bulbo** · 21/12/2007, 14h18

La 1 est la pire de toutes, tout ça pour économiser 5 caractères (set/get...() ) et tout d'un coup a moins d'avoir un compilo built-in on ne sait plus du premier coup d'œil si on appelle une méthode ou si on accède a un champ ..

J'appelle pas ça un gain, ni quelque chose d'envisageable, a se demander pourquoi Sun la propose..

Bulbo

**heid** · 21/12/2007, 14h45

Je viens du monde .net et depuis 6 mois je fais exclusivement du java. C'est vrai que les "bidouilles" du language comme celle proposée déforment l'idée de base du java qui est très "propre" et full object.

Les réaction se seraient pas du tout les mêmes dans les forums .net (ide unique très intrusif), je sui surpris mais au final je comprend parfaitement vos réactions.

**bulbo** · 21/12/2007, 14h51

Envoyé par heid

Je viens du monde .net et depuis 6 mois je fais exclusivement du java. C'est vrai que les "bidouilles" du language comme celle proposée déforment l'idée de base du java qui est très "propre" et full object.

Les réaction se seraient pas du tout les mêmes dans les forums .net (ide unique très intrusif), je sui surpris mais au final je comprend parfaitement vos réactions.

Bah c'est un des avantages de java que j'apprécie énormément, il a forcé les gens a réellement faire attention au design objet.

.Net peut lui dire un gros merci, tout plein d'API ont vu le jour (qui existent aussi en .Net aujourd'hui NHibernate, Nant ...), le design objet et les design patterns sont un sujet a la mode et les gens cherchent un peu plus a faire propre et efficace que tout a l'arrache comme dans le temps, même avec des langages très permissifs et bordéliques a la C++, .Net ...

Bulbo

**heid** · 21/12/2007, 14h57

Envoyé par bulbo

même avec des langages très permissifs et bordéliques a la C++, .Net ...

J'avais essayé de ne déclencher aucun troll dans mon poste précédent en choississant bien mes mots, tu ne t'es pas donné ce mal

**bulbo** · 21/12/2007, 15h08

Envoyé par heid

J'avais essayé de ne déclencher aucun troll dans mon poste précédent en choississant bien mes mots, tu ne t'es pas donné ce mal

C'est pas vraiment un troll, même les développeurs C++ le reconnaissent qu'il y a trop de choses de permises par le langage. Et C# est une repompe de ce qui a fait le succès de java sans le comprendre et donc en introduisant plein de possibilités pour que les développeurs MS gardent leurs mauvaises habitudes..

Ce sont des faits, difficile de troller avec ça. Je n'en aurais pas dit autant de SmallTalk ou d'Eiffel qui sont des langages purs objets et respectant les règles que devraient respecter tout langage se disant objet.

Bulbo

**heid** · 21/12/2007, 15h12

Postes ca sur .net versus java ou sur le général .net et on verra si c'est pas un troll

. (heureusement aucun développeur .net ne se risquerait à aller voir les specs java

)

**Benetl2008** · 21/12/2007, 21h23

Bonsoir,

La proposition 13, Accès aisé aux propriétés, part d'un bon sentiment mais n'est peut-être pas une bonne idée.
Utiliser de nouveaux accès (1, 2, ou 3) sera-t-il sans incidence avec les getter et setter des beans (struts ou autre) ?

La proposition 1 (classe.propriété) fait énormément penser à des structures en C ...

**Uther** · 21/12/2007, 22h14

Java a toujours eu pour but la compatibilité. Il est évident qui ne sera rien apporté de nouveau qui puisse casser des systeme existants.

**bassim** · 21/12/2007, 23h39

Envoyé par bulbo

Bah c'est un des avantages de java que j'apprécie énormément, il a forcé les gens a réellement faire attention au design objet.

.Net peut lui dire un gros merci, tout plein d'API ont vu le jour (qui existent aussi en .Net aujourd'hui NHibernate, Nant ...), le design objet et les design patterns sont un sujet a la mode et les gens cherchent un peu plus a faire propre et efficace que tout a l'arrache comme dans le temps, même avec des langages très permissifs et bordéliques a la C++, .Net ...

Bulbo

c'est aussi une des raisons qui ont fait que j'aime beaucoup ce langage !

**laurent_m** · 23/12/2007, 20h54

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

**azalsup** · 26/12/2007, 12h37

proposition 4 :
Person p = new Person();

p.forename( "Stephen" ); // calls setter created by the compiler
String str = p.forename(); // calls getter created by the compiler

**Tommy31** · 26/12/2007, 13h23

Pour, proposition 3 (#). Ce n'est pas tant l'écriture de l'accesseur, ou son appel qui pose problème, ca les ide s'en sortent très bien, mais plutot la relecture... Quelle verbosité. C'est flagrant quand on s'ammuse avec Groovy. Une égalité, c'est bien plus parlant qu'un set parenthésé.

**joho** · 02/01/2008, 10h36

Contre, parce que je ne comprends pas tellement l'utilité.
Autant utiliser les propriétés C# dans leurs totalités si c'est pour écrire p.Name = "Joho";

**g_rare** · 08/01/2008, 17h12

100% CONTRE

**gokud-o-matic** · 09/01/2008, 00h54

Envoyé par g_rare

100% CONTRE

d'abords, faut lacher la touche shift. ensuite, une explication, ce serait bien.

**zambizi** · 19/01/2008, 15h24

La proposition numero 1 me somble plus claire!
j'aime pas les (# et surtous les => )!!!

**zambizi** · 19/01/2008, 15h25

Envoyé par azalsup

proposition 4 :
Person p = new Person();

p.forename( "Stephen" ); // calls setter created by the compiler
String str = p.forename(); // calls getter created by the compiler

j'ai vus ça quelque part