Discussion :

[vbrabant]

Aujourd'hui :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
 
class Buffer {
    Buffer flip() { … }
    Buffer position(int newPos) { … }
    Buffer limit(int newLimit) { … }
}
class ByteBuffer extends Buffer {
    ByteBuffer put(byte data) { … }
}

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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

Demain :

Proposition 1 :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
class Buffer {
    this flip() { � }
    this position(int newPos) { � }
    this limit(int newLimit) { � }
}
class ByteBuffer extends Buffer {
    this put(byte data) { � }
}

Proposition 2 :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
 
class Buffer {
    This flip() { … }
    This position(int newPos) { … }
    This limit(int newLimit) { … }
}
class ByteBuffer extends Buffer {
    This put(byte data) { … }
}

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
ByteBuffer buf = ...;
buf.flip().position(12); // OK
buf.flip().put(12); // OK

[JPDMJC]

J'avoue �tre contre, et c'est mon vote .

Actuellement on doit faire attention � nos types, et faire figurer un transtypage incite - � mon humble avis - le d�veloppeur � faire attention � ce qu'il fait.

De plus, les syntaxes propos�es me font vite tourner la t�te.
Si je devais quand m�me choisir entre les deux syntaxes, je choisirai la n�1, pour le mot clef en minuscules.
Bref, comme le bon vieux this, tous les this quoi. Pourquoi diable se retrouver avec des this et des This ?

[metalpetsFR]

Bonjour
Tout d'abors merci pour ce d�bat int�ressant
Personnellement je suis plutot contre

Quand tu dis m�me type, c'est pas plutot meme instance car des m�thode comme String#toUpper() renvoi le m�me type mais pas la m�me instance, et dans ce cas l'utilisation de this serait conceptuellement faux.

De plus casting devenant implicit, le developpeur se rendrait m�me plus compte du probl�me potentiel.
Un peu comment quand on fait :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
Arrays.asList(new String[]{"toto"}).add("titi");

[adiGuba]

J'ai vot� pour � cette proposition ainsi qu'� la proposition 6, mais en fait j'h�site entre les deux...

Celle-ci a l'avantage d'�tre d�clarative (on voit bien que la m�thode retourne l'instance courante), mais cela doit �tre g�r� par la classe.

La proposition 6 �tend cela � toutes les m�thodes retournant void, mais dans ce cas c'est les m�thodes retournant le m�me type qui poseront probl�me


@metalpetsFR : cela ne doit �tre utilis� qu'avec les m�thodes utilisant return this et non pas une copie de l'objet comme c'est le cas des m�thodes de String...

a++

[austin P.]

contre
le typage implicite est une bonne chose : on sait ce qu'on fait

et puis si on y tiens on peut encore s'en sortir avec des generics

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
 
class Buffer<T extends Buffer> {
    T flip() {return null;}
    T position(int newPos) { return null;}
    T limit(int newLimit) {return null; }
}
class ByteBuffer extends Buffer<ByteBuffer> {
    ByteBuffer put(int data) {return null; }
}

[adiGuba]

et puis si on y tiens on peut encore s'en sortir avec des generics

Mouais...
C'est une solution mais elle a encore plus de limite je trouve :
On connait le type de T mais l� on n'est pas s�r que cela correspond � this, alors que dans la proposition cela pourrait �tre v�rifi� par le compilateur.

Je veux dire par l� que j'attend de cette proposition qu'un code comme celui-ci g�n�re une erreur :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
public MaClasse {
 
	public This doSomething() {
 
		// ...
		return new MaClasse(); // ERREUR
	}
 
}

car la seule valeur de retour doit �tre this.


Dans ton exemple avec les Generics cela n'est pas garantit et le sens est donc un tout petit peu diff�rent...

De plus cela alourdit le code si on utilise directement Buffer :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Buffer<Buffer> buffer = new Buffer<Buffer>();

Et le probl�me se retrouve �galement dans la classe ByteBuffer car si on veut toujours permettre cela aux classes filles il faudrait faire ceci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
class ByteBuffer<T extends ByteBuffer> extends Buffer<T> {
    ByteBuffer put(int data) {return null; }
}

Et ainsi de suite...

a++

[austin P.]

Mouais...
C'est une solution mais elle a encore plus de limite je trouve :
On connait le type de T mais l� on n'est pas s�r que cela correspond � this

il me semblait que l'on cherche le m�me type et pas this

pour l'ecriture avec des generics par contre tu as raison : c'est plus complexe
et limitatif

[bobuse]

J'ai vot� pour � cette proposition ainsi qu'� la proposition 6, mais en fait j'h�site entre les deux...

Moi, je n'h�site pas. Je choisis la 6 ! Au moins, c'est clair et puis je n'aime pas du tout ce this. Et puis je trouve �a trop compliqu�, que �a ne marche que si tu retourne l'objet courant … autant mettre void, et laisser la prop 6 faire le boulot !!

La proposition 6 �tend cela � toutes les m�thodes retournant void, mais dans ce cas c'est les m�thodes retournant le m�me type qui poseront probl�me

Et bien hop, tu enl�ves le type de retour, le return this, ant build, et �a roule

[adiGuba]

autant mettre void, et laisser la prop 6 faire le boulot !!

Oui mais dans ce cas c'est toutes les classes qui retourne d�j� le m�me type qui poseront probl�me, car passer de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Buffer flip();

�

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

void flip();

doit poser pas mal de probl�me de compatibilit�...

Alors qu'on peut penser que passer � :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

This flip();

devrait �tre valide si les types correspondent...

a++

[bobuse]

Ha oui, encore cette satan� compatibilit� !
C'est b�te quand m�me … mais tu as certainement raison.

[bulbo]

Contre,

J'ai du mal a voir �a en application et �a fait doublon avec le chainage des appels que je n'aime pas non plus..

C'est moins pire que le chainage et certaines m�thodes retournent d�j� l'objet this (avec un type fixe par contre) donc �a ne change pas �norm�ment de choses, mais je trouve qu'en cas d'h�ritage c'est bof bof a suivre et quid des effets de bords qui pourraient �tre possible (enfin ils seraient peut-�tre possible aussi aujourd'hui)

Un petit contre finalement, je hurlerai pas si �a passe

Bulbo

[adiGuba]

mais je trouve qu'en cas d'h�ritage c'est bof bof a suivre

Justement l'int�r�t vient en cas d'h�ritage !

Actuellement pour �viter ce probl�me il faut red�finir toutes les m�thodes parentes dans la classe fille en changeant le type de retour (grace � la covariance), par exemple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Buffer {
    Buffer flip() { … }
    Buffer position(int newPos) { … }
    Buffer limit(int newLimit) { … }
}
 
class ByteBuffer extends Buffer {
    ByteBuffer put(byte data) { … }
 
    // Et on redéfinit les méthodes parentes :
    ByteBuffer flip() { return (ByteBuffer) super.flip(); }
    ByteBuffer position(int newPos) { return (ByteBuffer) super.position(newPos); }
    ByteBuffer limit(int newLimit) { return (ByteBuffer) super.limit(newLimit); }
}

encore faudrait-il �tre s�r que les m�thodes parente retourne bien this...


Avec le type This en retour cela serait inutile et on est s�r qu'elles retourneront bien this (enfin c'est comme cela que je l'ai compris en tout cas).

a++

[metalpetsFR]

Syntaxiquement on ne peut pas v�rifier le type r�el de l'objet meme si c'est la meme instance

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Buffer {
    This flip() { … }
    This position(int newPos) { … }
    This limit(int newLimit) { … }
}
class ByteBuffer extends Buffer {
    This put(byte data) { … }
}
 
 
Code :
ByteBuffer buf = ...;
buf.flip().position(12); // OK
buf.flip().put(12); // OK

buf.flip() retourn buf mais rien nous assure que buf et instance de ByteBuffer

[adiGuba]

Syntaxiquement on ne peut pas v�rifier le type r�el de l'objet meme si c'est la meme instance

Ce que je veux dire c'est que pour moi une m�thode qui d�clare retourner This (ou this peut importe) devrait obligatoirement retourner this et non pas un objet du m�me type :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
class Buffer {
   public This flip() {
       ...
       return this; // OK
   }
}

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
class Buffer {
   public This flip() {
       ...
       return new Buffer(); // ERREUR
   }
}

En tout cas c'est pour cela que j'ai vot� Oui, sinon je vote contre car cela apporterait plus d'ambiguit� qu'autre chose et je ne vois pas la diff�rence avec l'utilisation du type directement...

a++

[bulbo]

Je suppose qu'il n'y aurait pas de return dans ce type de m�thode, donc on serait sur de retourner this.

Pour faire plaisir, un pour du bout des l�vres, m�me si je ne vois pas bien l'int�r�t.. a part �viter des casts ou des red�finitions appelant simplement super..

Bulbo

[adiGuba]

Pour faire plaisir, un pour du bout des l�vres, m�me si je ne vois pas bien l'int�r�t.. a part �viter des casts ou des red�finitions appelant simplement super..

L'int�r�t est de permettre aux classes de proposer du chainages d'invocation tout en permettant un h�ritage.

Tu peux prendre l'exemple des vrai classes Buffer -> ByteBuffer -> MappedByteBuffer :

http://javasearch.developpez.com/j2s...io/Buffer.html
http://javasearch.developpez.com/j2s...yteBuffer.html
http://javasearch.developpez.com/j2s...yteBuffer.html

Afin de permettre le chainage la plupart des m�thodes de ces classes renvoi le type courant. Le probl�me c'est que le chainage n'est pas toujours possible comme on le souhaite car si on appelle une m�thode de la classe parente on "perd" le type courant et on a � la place le type parent :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
MappedByteBuffer mbb = new MappedByteBuffer();
mbb.flip(); // retourne un Buffer

Comme la m�thode flip() est d�fini dans Buffer elle d�clare retourn� le type Buffer et on ne peux plus chain� avec une m�thodes des types fils (ByteBuffer ou MappedByteBuffer) alors qu'elle retourne bien this (et donc un MappedByteBuffer).


a++

[bulbo]

Pas taper j'ai chang� mon vote d�j� .. enfin dans le topic, je peux pas changer le sondage malheureusement

S�rieusement, je suis d'accord avec tes arguments adiGuba, j'aurais du tourner mon clavier sept fois dans ma bouche avant de r�pondre a ce sondage mais fai pfa pfafile

Bulbo

[lunatix]

si on veut que ca soit utile, il faut aussi revoir la definition d'un bean, sinon, on encore le meme probleme avec les seters qui ne peuvent pas renvoyer this pour etre conformes

[adiGuba]

si on veut que ca soit utile, il faut aussi revoir la definition d'un bean, sinon, on encore le meme probleme avec les seters qui ne peuvent pas renvoyer this pour etre conformes

On peut tr�s bien �tre conforme en renvoyant this... mais dans ce cas il faut �crire une classe BeanInfo qui g�re tout cela (mais je te l'accorde c'est assez lourd).

a++

[divxdede]

Cette proposition m'interpelle car je n'arrive pas a trancher.

L'objectif est sensiblement le m�me que la proposition d'invocations chain�es (pour laquelle je suis contre dans sa forme propos�e).

Je vais voter contre, mais il est interressant de converger les id�es et de proposer une forme � l'invocation chain�e qui �vite toute ambiguit�e.