Discussion :

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

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.

[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

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

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

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

[lvr]

Ce problème de devoir faire un Cast est gonflant.
Je préfère le "This" au "this" car pour moi le "this" est une instance et pas une classe. "This" correspond plus dans mon esprit à la notion de classe.

[TPReal]

J'aime l'idee, mais je ne pense pas que ca ferait programmation serieusement plus facile. Et oui, 'This' est meilleur, 'this' est l'instance de la classe, alors 'This' peut etre la classe.

[Dog Eata]

La proposition permet d'écrire simplement ce que les types génériques permettent déjà de faire de manière un peu lourde.
Je suis pour les deux propositions car elles elles pourraient signifier deux choses différentes :

• This indiquerait que le type de retour doit être le même que celui de la classe qui implémente la méthode
• this indiquerait carrément que l'objet retourné est la même instance de la classe sur laquelle on a invoqué la méthode

A mon sens ces deux notions peuvent être utiles; sachant que la deuxième est une vraie nouveauté.

[Traroth2]

J'aime bien la proposition 2 : This, classe de l'objet this. Ca suit la notation conseillée pour Java, c'est très clair, je trouve.

[xavlours]

Pour la proposition 2, mais pas pour les appels chaînés, plutôt pour des méthodes comme clone().

C'est juste que j'ai toujours été frustré de me faire ch... à bien vérifier mes generics, et à quand même me taper les warnings à cause d'un clone. C'est pas pour faire mon râleur, c'est juste que je trouve l'illustration mal choisie. Je suis pas fan des appels chaînés, mais l'utilisation d'un type This combiné avec les generics peut apporter de l'expressivité (je crois).

[adiGuba]

Pour la proposition 2, mais pas pour les appels chaînés, plutôt pour des méthodes comme clone().

Hum en effet cela pourrait être vraiment pas mal !

Par contre je me demande s'il est possible de modifier la définition de clone() sans casser la compatibilité...

a++

[xavlours]

Par contre je me demande s'il est possible de modifier la définition de clone() sans casser la compatibilité...

En théorie, ça devrait être faisable, puisque l'objet renvoyé par clone() doit être du même type que l'objet d'origine. Mais rien ne le garantit à la compilation (ni même à l'exécution).
On peut imaginer une implémentation de List tellement exotique (ou crade) que le développeur décide de renvoyer une ArrayList ou une LinkedList lors du clone. Si cette List est fournie par une Factory, l'utilisateur ne s'en rendra même pas compte à l'exécution, puisqu'il manipule une List, et qu'il caste son clone en List. Par contre, le jour du changement de JRE, ça plante.

Mais tant pis pour eux, je suis toujours pour .

[kpouer]

Ca pourrait être pas mal car la syntaxe des generics style
ByteBuffer extends Buffer<ByteBuffer>
ou la classe se passe elle même en paramètre de sa mère est un peu moche par contre un mot clef différent de this serait le bienvenu, peut être un <this> pour bien différencier les 2 non ?

[djo.mos]

Voté pour la proposition 1 (pas la 2) comme ça, on évite d'ajouter un nouveau mot clé/type et on évite de casser ceux qui ont eu la malchance de nommer un de leurr type par
This.

Voté pour en général car ça permet de bâtir des APIs plus solides et extensibles: ça peut ne pas intéresser ceux qui mangent leur propre côde, mais dans les cas où on batît une couche sur laquelle d'autres bâtiront leur propre couche, etc., cette fonctionnalité est un must !

P.S.: J'ai voté contré le chainage des appels void.

[jproto]

En fait, ni l’une ni l’autre ne me séduisent.
Niveau maintenance, je pense que le cast obligatoire a ses vertus.

Je suis donc contre.

[JHelp]

Je suis plutôt pour. On a ici une explication clair de ce que retourne la méthode.
Par contre j'utiliserais This avec une majuscule pour l'instance et un mon clef style SameType pour le même type, pour ne pas avoir de confusion.
Car si on lit un peu vite, This et this ça se ressemble beaucoup et j'imagine la confusion que pourrait en faire un débutant.
JHelp

[Reizz]

Bonsoir,
Je suis assez d'accord avec cette proposition :

pour indiquer que la méthode retournera this :

Code :

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

1
2
3
4
5
public this maMethode()... {
//des choses
//...
return this; //optionnel
}

et sans majuscule car this est suffisamment explicite. (avec bien sur interdiction public static this methode()...)
si j'ai bien compris qu'on ne parle que d'instance et non de classe.


Par contre si on ne parle que de type:
Si c'est pour avoir la même classe quelque soit l'instance je trouve ça risqué :

Code :

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

1
2
3
4
5
6
7
8
9
10
class A {
  public A renvoie(){ return new B() };
}
 
class B extends A {
}
 
class C extends A{
  public C renvoie(){ return (C)super.renvoie() };
}

appel:

Code :

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

1
2
C c = new C();
C c2 = c.renvoie();

et là ClassCastException de B vers C.

Peut être je me trompe mais je trouve que c'est plutôt dangereux de vouloir masquer un cast déjà potentiellement dangereux.

A bientôt.