JDK 7: Proposition 13 : Accès aisé aux propriétés

Version imprimable

Voir 40 message(s) de cette discussion en une page

Accès aisé aux propriétés

Proposition 1 :
En utilisation le point comme séparateur

Code:

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:

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:

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

19/12/2007, 09h35
metalpetsFR

Et pourquoi pas appelé la méthode setAge() définit implicitement?
19/12/2007, 10h06
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
19/12/2007, 11h04
austin P.

contre

n'apporte pas grand chose et je ne trouve pas la lecture plus clair
19/12/2007, 11h39
OButterlin

Pour la 1, si on peut continuer à utiliser les getter/setter
19/12/2007, 11h59
heid

pour la 1 (existe en c# et est très pratique).
19/12/2007, 12h06
BakaOnigiri

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

Citation:

Envoyé par BakaOnigiri

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

C'est exactement ce que je pense aussi.

Ça ne permet que d'économiser que quelques caractères, et rend l'instruction confuse.
19/12/2007, 12h35
cisco

j'ai voté 1 par ce que je trouve que le mécanisme C# est bien

Contre la 1 sinon je ne vois pas comment on va distinguer une variable public d'une propriété public.
Quand on utilise un get/set on suppose qu'il y a un mecanisme de protection contre les erreurs de parametres etc...
Quand on a une variable public (donc on utlise le .) on sait qu'il n'y a aucune sécurité. Donc on ne code pas de la meme maniere.
Code:

1 2 3 4 5 6 7 8 9 10 11 public class Person { public property String forename; public property int age; public String pseudo; } Person p = new Person(); p.forename = "Stephen"; // calls setter String str = p.forename; // calls getter String str2 = p.pseudo; // calls rien du tout!!!
donc si "property" il y a, il ne faut surtout pas utiliser le '.'
je vote pour le # qui permet de les differencier :
Code:

1 2 3 4 5 6 7 8 9 10 11 public class Person { public property String forename; public property int age; public String pseudo; } Person p = new Person(); p#forename = "Stephen"; // calls setter String str = p#forename; // calls getter String str2 = p.pseudo; // calls rien du tout, mais on le sait
ps : j'ai voté contre les "property" donc je vote au cas où ici :aie:

19/12/2007, 14h21
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 ;)
19/12/2007, 14h28
OButterlin

C'est vrai que le "." va poser problème pour les propriétés "public", il va bien falloir distinguer
19/12/2007, 14h52
heid

Sous visual studio cette différentiation se fait dans l'infobulle et dans l'icone du champ de l'autocomplétion ou on peut différentier un champ d'une propriété. Pour ma part ca ne m'a jamais posé problème, à vrais dire je n'avais jamais remarqué le problème.

Le # me semble une très mauvaise idée au contraire.
19/12/2007, 15h07
eclesia

Citation:

Envoyé par heid

Sous visual studio cette différentiation se fait dans l'infobulle et dans l'icone du champ de l'autocomplétion ou on peut différentier un champ d'une propriété. Pour ma part ca ne m'a jamais posé problème, à vrais dire je n'avais jamais remarqué le problème.

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

Java n'est pas C#. M$ fait ce qu'il lui plait, libre a lui de nous empecher de faire la difference entre un '.' (propriété) et un '.' (variable public) sans son editeur propriétaire.

Ok le # n'est pas forcement le bon séparateur. un ^ ou ! serait pas mal non plus du moment qu'on peut faire la difference.
19/12/2007, 15h16
heid

Citation:

Java n'est pas C#

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

Contre même si cela ne me dérangerait pas...

Mis à part la première solution qui est vraiment affreuse car elle porte à confusion : on ne devrait pas avoir besoin d'un EDI pour savoir ce que fait une ligne de code !!!

Par contre j'avais vu une proposition bien plus intéressante qui consistait à avoir accès aux informations de réflections des méthodes et propriétée javabeans de manière static tout comme le .class :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 MyObject instance = new MyObject(); // On récupère le type de manière static : Class<MyObject> type = MyObject.class; // On récupère une méthode de manière static : Method<MyObject, String> method = MyObject#toString(); String s = method.invoke(instance); // équivalent à instance.toString() // On récupère une propriété et ses getter/setter de manière static : Property<MyObject, String> property = MyObject#name; String s = property.get(instance); // équivalent à instance.getName() property.set(instance, "newName"); // équivalent à instance.setName("newName")
:arrow: ceci me brancherait bien plus ;)

a++

19/12/2007, 16h14
bobuse

Citation:

Envoyé par adiGuba

Par contre j'avais vu une proposition bien plus intéressante qui consistait à avoir accès aux informations de réflections des méthodes et propriétée javabeans de manière static tout comme le .class

:D :D Tu as des réfs ??
Tu peux pas imaginer ce que je donnerai pour avoir ça !! Car, utilisant pas mal la réflexivité, ça me fait toujours mal de devoir faire une référence avec une chaîne de caractère, qui n'est pas du tout vérifiée à la compilation, et reste très approximatif.

Code:

Method<MyObject, String> method = MyObject#toString();

Ça serait vraiment excellent !!! :D
19/12/2007, 16h19
adiGuba

Citation:

Envoyé par bobuse

:D :D Tu as des réfs ??

Non malheureusement... :cry:

J'ai retranscrit cela de mémoire... mais si je retrouve la proposition je la posterais ici ;)

a++
19/12/2007, 19h11
elitost

Aucune proposition vraiment satisfaisante.
19/12/2007, 23h25
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.

Voir 40 message(s) de cette discussion en une page