Discussion :

[super_navide]

Le même problème se pose avec la méthode clone de Object

Code :

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

1
2
3
4
5
6
 class Object { 
 
abstract Object clone( ) ; }
 
Truc bidule = new Truc( ) ;
Truc cloneBidule = (Truc)bidule.clone( ) ;

moi j'ai voté oui car je trouve ca utile et logique
une méthode qui clone un objet renvoit toujours un objet de même type que le receveur

[Uther]

Sauf que dans ce cas précisément ça n'a pas de sens vu que le but du clonage est justement de ne pas retourner this mais une nouvelle instance.

A mon avis la encore c'est a la classe fille de bien faire son boulot et de retourner le type adéquat. Je ne sens pas le besoin de rajouter un mot clé pour pallier une mauvaise conception de la classe fille.

[fabszn]

Hello,

Je vote définitivement pour la proposition 1!

Pourquoi la proposition 1 plutôt que la 2, car l'ajout d'un nouveau mot clef n'a pa de réel intérêt, deplus le mot clef this remplie parfaitement cette fonction.

En effet, la mise en place de ce this comblerait un manque au typage de Java.

En effet, l'utilisation du cast dans le cas décrit en exemple :

Code :

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

1
2
3
4
5
 
      ByteBuffer buf = ...;
buf.flip().position(12); // OK
buf.flip().put(12); // Error
((ByteBuffer)(buf.flip())).put(12); // Obliged to cast

montre une faiblesse du typage du language Java.
En effet, on manipule un objet de type ByteBuffer et on est obligé de le donwcaster pour faire appel à une de ses méthodes.

Dans un language comme Ocaml, on nomme cette notion le selftype.

En introduisant, ce this on permet, en cas d'héritage, de faire évoluer les types retours de chaque méthode retournant l'objet courant en les spécialisants.

En faisant celà, on élimine le recourt au transtypage (qui relève selon moi d'une mauvaise conception et d'un mauvaise pratique).

D'alleurs, les générics et la de la covariance suivent la même idée, c'est à dire l'élimination du cast (qui engendre une plu grande sécurité au niveau du code).
Avec ces évolutions, on renforce le typage de Java.

Je trouve que cette proposition ressemble plus à une vrai évolution vers un vrai language objet, que la proposition 6 qui est, selon moi, plus une évolution de la syntaxe.

[fabszn]

Hello,

Le même problème se pose avec la méthode clone de Object

Code :

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

1
2
3
4
5
6
 class Object { 
 
abstract Object clone( ) ; }
 
Truc bidule = new Truc( ) ;
Truc cloneBidule = (Truc)bidule.clone( ) ;

moi j'ai voté oui car je trouve ca utile et logique
une méthode qui clone un objet renvoit toujours un objet de même type que le receveur

La covariance permet justement d'éviter ce genre de chose.

Sauf que dans ce cas précisément ça n'a pas de sens vu que le but du clonage est justement de ne pas retourner this mais une nouvelle instance.

Je pense que là on ne parle pas d'une instance, mais plutôt du type de l'objet retourné.

A mon avis la encore c'est a la classe fille de bien faire son boulot et de retourner le type adéquat. Je ne sens pas le besoin de rajouter un mot clé pour pallier une mauvaise conception de la classe fille.

Lorsqu'une classe possède des méthodes retournant l'objet courant, il est appréciable ( et normal) que les classes qui en hérite n'est pas à se soucier (pour ces méthodes) du type à retourner.

Si je suis au niveau de la classe buffer, je m'attends à avoir, comme type retour un objet de type Buffer, en revanche lorsque je suis au niveau de la sous-classe les mêmes méthodes renvoie la même référence mais vu comme le sous type, ce qui est finallement logique!

Imaginons une classe possédant 150 méthodes retournant le type courant, voila la charge de travail pour le développeur pour reprendre l'ensemble des méthodes afin qu'elles renvoient le bon type...

En effet, la notion qu'engendre ce this dit que le type de l'objet retour se raffine en même temps que l'on descend dans l'arbre d'héritage et celà grace à une certaine rigueur du typage par le language.

[pseudocode]

D'une manière générale "Contre" les 2 propositions.

En tous cas un TRES GROS "Contre" la proposition 1. En java, le mot clé "this" représente une instance (référence) et non pas un type (classe).

Java est un langage fortement typé, en conséquence le type de retour doit etre associé au moment de sa déclaration (ici au nom de la méthode).

Au mieux, ca serait à l'ecriture de la classe fille qu'il faudrait apporter des améliorations, par exemple avec les annotations:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Buffer {
    Buffer flip() { ... }
    Buffer position(int newPos) { ... }
    Buffer limit(int newLimit) { ... }
}
 
@generateSelfTypeDecorators("Buffer")
class ByteBuffer extends Buffer {
    ByteBuffer put(byte data) { ... }
}

[adiGuba]

Au mieux, ca serait à l'ecriture de la classe fille qu'il faudrait apporter des améliorations, par exemple avec les annotations:

Je trouve au contraire que c'est à la classe parente d'indiquer si elle retourne this ou une copie, sinon comment différencier ces deux méthode (autrement que par leurs noms) :

Code :

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

1
2
public Buffer flip();
public Buffer clone();

La première retourne this afin de pouvoir utiliser le chainage de méthode.
La seconde retourne une autre instance de Buffer.


Avec cette proposition tout est clairement défini :

Code :

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

1
2
public this flip();
public Buffer clone();

a++

[pseudocode]

Je trouve au contraire que c'est à la classe parente d'indiquer si elle retourne this ou une copie, sinon comment différencier ces deux méthode (autrement que par leurs noms) :
(...)

Je suis d'accord avec toi sur la "beauté" de l'aspect syntaxique.

Ce qui me dérange est plus un probleme de conception. Ca me semble bizarre que ca soit à la classe parente de spécifier la manière dont elle sera étendue par les futures classes filles (qui n'existent pas encore).

C'est deja assez compliqué de concevoir une classe qui reponde à une problematique "metier" sans, en plus, rajouter une problematique de "plomberie" Java.

J'ai l'impression qu'on prend le probleme à l'envers: sous pretexte de faciliter l'utilisation (i.e. l'appel des methodes) d'une classe, on complexifie sa déclaration. Si le "cast" est vraiment si penible que cela, il n'y a qu'a étendre la notion d'autoboxing. Non ?

[adiGuba]

Ce qui me dérange est plus un probleme de conception. Ca me semble bizarre que ca soit à la classe parente de spécifier la manière dont elle sera étendue par les futures classes filles (qui n'existent pas encore).

Ben c'est déjà le cas : lorsque tu implémentes/redéfinis une méthode tu as un certain nombre d'éléments à respecter, qui sont défini par la classe ou l'interface d'où provient cette méthode...

C'est deja assez compliqué de concevoir une classe qui reponde à une problematique "metier" sans, en plus, rajouter une problematique de "plomberie" Java.

Justement c'est maintenant qu'il faut faire de la "plomberie".
Si tu veux étendre la classe Buffer défini dans le premier post :

Code :

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

1
2
3
4
5
class Buffer {
    Buffer flip() { … }
    Buffer position(int newPos) { … }
    Buffer limit(int newLimit) { … }
}

Actuellement tu as deux solutions :

1. Soit tu te contente d'ajouter tes nouvelles méthodes :
   

   Code :

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

   1
   2
   3
   class ByteBuffer extends Buffer {
       ByteBuffer put(byte data) { … }
   }

   Mais dans ce cas tu ne pas utiliser le chainages sans cast disgracieux (et ca c'est de la "plomberie").
   
   
2. Soit tu redéfinis les méthodes de la classe Buffer pour adapter le type de retour (via la covariance) :
   

   Code :

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

   1
   2
   3
   4
   5
   6
   7
   class ByteBuffer extends Buffer {
       ByteBuffer flip() { super.flip(); return this; }
       ByteBuffer position(int newPos) { super.position(newPos); return this; }
       ByteBuffer limit(int newLimit) { super.limit(newLimit); return this; }
    
       ByteBuffer put(byte data) { … }
   }

   Ca aussi c'est de la "plomberie" et c'est vachement lourd si tu as une vingtaine de méthode et plusieurs niveaux de classes...

J'ai l'impression qu'on prend le probleme à l'envers: sous pretexte de faciliter l'utilisation (i.e. l'appel des methodes) d'une classe, on complexifie sa déclaration. Si le "cast" est vraiment si penible que cela, il n'y a qu'a étendre la notion d'autoboxing. Non ?

Cela ne ferait que multiplier les problèmes. Prenons cette méthode qui serait défini dans la classe Buffer :

Code :

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

public Buffer method();

Est-ce qu'elle renvoi this ? Est-ce qu'elle renvoi une autre instance de Buffer ?
Si on l'appelle depuis la classe ByteBuffer rien ne garantit que le type de retour soit bien un ByteBuffer, d'où le cast !


Le problème ne vient pas des quelques caractères en plus du cast. Mais il faut bien comprendre qu'un cast signifie "problème de type potentiel", et que le fait d'enlever un cast doit enlever ce problème potentiel.



Ici l'objectif est de définir un moyen de dire :

• Cette méthode renvoi une référence vers l'instance courante.

Alors qu'actuellement on doit se contenter de :

• Cette méthode renvoi un objet du même type.

Et avec cette seconde solution on prend en compte un cadre particulier qui permet de simplifier la gestion du chainage


Et là justement on peut se passer de la plomberie, puisqu'on pourrait même rendre le return implicite (après tout on ne peut faire que return this).


a++

[pseudocode]

@adiGuba: tres jolie explication . Ce qui m'amene à la question:

Est-ce que cette "proposition 10" à un autre interet que de faciliter le chainage ?

[adiGuba]

Est-ce que cette "proposition 10" à un autre interet que de faciliter le chainage ?

A mon avis : non !


a++

[pseudocode]

A mon avis : non !

C'est aussi ce que je me disais.

Dans ces conditions ne serait-il pas plus simple de modifier la syntaxe du coté "chainage" que du coté "déclaration" ?

[adiGuba]

Dans ces conditions ne serait-il pas plus simple de modifier la syntaxe du coté "chainage" que du coté "déclaration" ?

Ca dépend. Tout utiliser en chainage n'est pas forcément plus clair, et la "déclaration" a un coté un peu plus "strict"...

a++

[pseudocode]

Ca dépend. Tout utiliser en chainage n'est pas forcément plus clair, et la "déclaration" a un coté un peu plus "strict"...

Peut-etre meme un peu trop strict. Par exemple, au niveau "interface", ca risque d'etre problématique. Si on utilise "this" dans la déclaration des methodes de l'interface, on impose l'implémentation => Impossible de faire de la décoration.

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
interface IBuffer {
    this flip();
}
 
class Buffer implements IBuffer {
    public this flip() { }  // <-- ok
}
 
class SafeBuffer implements IBuffer {
    private Buffer bsafe;
    public this flip() { return bsafe.flip(); }  //  <-- impossible
}

[adiGuba]

Au contraire ce sera plus propre car on serait obligé de bien renvoyer this :

Code :

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

1
2
3
4
5
6
7
class SafeBuffer implements IBuffer {
    private Buffer bsafe;
    public this flip() {
        bsafe.flip();
        return this; // <= Pourrait être implicite
    }
}

On renvoi bien un Safebuffer et on reste dans notre décorateur

a++

[pseudocode]

Au contraire ce sera plus propre car on serait obligé de bien renvoyer this
On renvoi bien un Safebuffer et on reste dans notre décorateur

Arf. J'suis trop bete. . Bien sur, tu as raison: c'est plus propre comme ca.

Ca me donnerait meme envie de voter "oui" à cette proposition.

NB: Pour ma part, je trouve que ce dernier exemple est plus parlant que celui proposé dans le PO. (forcer les setter a renvoyer "this" pour faciliter le chainage, ca fait pas propre).

[esteban]

Bonjour,

j'ai voté contre moi aussi car, même si c'est un peu casse-cxxxx de faire des cast explicites, parfois un peu compliqués, mais c'est selon moi la seule manière de préserver une bonne lecture du code, une gestion rigoureuse des types et surtout un débogage rapide.

[kisame]

contre comme pour esteban.

[vbrabant]

Je suis totalement pour.
Cela va vraiment apporter un grand plus et vraiment améliorer à la compréhension exacte du code. On va être sur que l'objet retourné est un objet du même type (cas 2), ou le même objet (cas 1).

Si on avait eu cela, on aurait pu avoir une interface de type Singleton qui définissait une méthode comme
This getInstance();

Et avoir des classes qui implémente cette interface Singleton. Et on était sûr que lorsqu'on appelait la méthode getInstance, on avait bien un objet du type de notre classe.

Exemple concret:

Code :

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

1
2
interface Singleton {
This getUniqueInstance();

Code :

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

1
2
3
4
5
6
7
8
class MaClasse implements Singleton {
  private MaClasse singleton = new MaClasse();
  private MaClasse() {...}
  public static This getUniqueInstance() {
     return singleton;
  }
  ...
}

Code :

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

1
2
3
4
5
6
7
8
class MonAutreClasse implements Singleton {
  private MonAutreClasse singleton = new MonAutreClasse();
  private MonautreClasse() {...}
  public static This getUniqueInstance() {
     return singleton;
  }
  ...
}

Moi, je trouve cela super pratique. Et l'exemple ci-dessus n'en est qu'un, bidon, parmis plein d'autres beaucoup plus pratique.
Si cela était rajouté dans le JDK 7, c'est parmis toutes les propositions présentées ici, celle que j'utiliserais le plus, avec le try {} catch {x|y|z}.
Maintenant, il est vrai que mon rôle dans ma compagnie est plus de développer des API qui seront réutilisés par d'autres.
Mais c'est clair qu'en tant que créateur d'API réutilisable par d'autres, cette fonctionnalité est vraiment, vraiment très intéressante et pratique.

Je trouve, personnellement, que cette proposition a été mal "vendue", mal présentée. En effet, Neal illustre cette proposition avec le chainage d'appel de méthode. Une pratique dont certain d'entre vous sont allergiques. Et je suis sûr que la plupart d'entre vous ont voté NON pour cette proposition, juste parce que vous êtes contre le chainage d'appel.


Vincent

[lpetit]

Je ne crois pas l'avoir vu cité dans les 4 pages de ce thread, mais ce qui est proposé ici ressemble à s'y méprendre à un sous-cas des "anchored declarations" (désolé, je n'ai pas la traduction francaise en tête) du langage Eiffel (déjà présent dans le langage Eiffel en 1990 :-)
lien : http://archive.eiffel.com/doc/online...l#pgfId-515701

Eiffel va même plus loin que ce qui est proposé (notamment on peut aussi utiliser le mot clé proposé 'This' dans des arguments de la méthode, et on peut lier des arguments entre eux sans qu'ils soient du type de la classe.

Ca permet d'etre plus concis dans l'ecriture de la classe et des classes filles, et d'avoir plus de verifications par le compilateur, moins de casts explicites dans les classes utilisatrices, et les IDEs pourraient a la volée, dans la complétion automatique, remplacer les "ancres de type" comme le 'This' par le type correspondant à la complétion en cours (toujours en typage statique fort, basé sur le type donné à la variable pour laquelle on propose la complétion automatique).

Utilisation classique qu'on pourrait avoir : si des template methods s'appuient sur le type de la classe en retour, il ne serait plus nécessaire de choisir entre soit redéfinir la template méthode pour renvoyer le type de retour de la sous-classe (code inutile dans la sous-classe), et soit faire des casts explicites dans la classe utilisatrice (alors qu'avec la nouvelle proposition le compilateur peut vérifier cela).

Cela peut effectivement être simulé avec les Generics : création d'un paramètre formel contraint sur le type de la classe, et dans les classes filles, renforcement de la contrainte sur le type des classes filles.
Mais : c'est lourd, répétitif dans chaque sous-classes et avec risque d'oubli (donc d'erreur), et ca ne permet pas d'exprimer ni aussi clairement, ni avec certitude, la contrainte "le type retourne doit toujours correspondre au type courant" au niveau de la classe mère.

C'est donc un très grand plus pour moi : c'est quasi transparent pour les utilisateurs des classes, avec les possibilités des IDEs modernes (une fois adaptés bien sûr), et également plus sûr pour eux.

Et c'est intéressant pour les concepteurs de hiérarchies de classes réutilisables.

[jproto]

Après relecture de l’ensemble de ce thread je dois admettre être plus mitigé.

Je reste sur l’idée que le cast explicite a ses vertues du point de vue de la maintenance. Cependant, mon vote initial était sûrement influencé vis-à-vis de la proposition 6 (http://www.developpez.net/forums/sho...d.php?t=460131) pour laquelle je reste contre.

En revanche, il a été mis en évidence des possibilités de créations de classes plus simples à exploiter sans pour autant remettre en cause la compréhension puisque contrairement à la proposition 6, il ne s’agit pas ici de modifier le comportement d’une fonction signée volontairement avec un retour void, mais d’exploiter des fonctions clairement définies avec un retour This.

Bref, je serais bien enclin à changer mon vote sur cette proposition. Cela m’apprendra à voter trop vite.

Chris