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

[vbrabant]

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

[metalpetsFR]

Et pourquoi pas appelé la méthode setAge() définit implicitement?

[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

[austin P.]

contre

n'apporte pas grand chose et je ne trouve pas la lecture plus clair

[OButterlin]

Pour la 1, si on peut continuer à utiliser les getter/setter

[heid]

pour la 1 (existe en c# et est très pratique).

[BakaOnigiri]

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

[bobuse]

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.

[cisco]

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

[eclesia]

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

[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

[OButterlin]

C'est vrai que le "." va poser problème pour les propriétés "public", il va bien falloir distinguer

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

[eclesia]

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.

[heid]

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

[adiGuba]

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")

ceci me brancherait bien plus

a++

[bobuse]

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

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 !!!

[adiGuba]

Envoyé par bobuse

Tu as des réfs ??

Non malheureusement...

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

a++

[elitost]

Aucune proposition vraiment satisfaisante.

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