JDK 7: Proposition 10 : Le même type [Débat]

[vbrabant]

Aujourd'hui :

Code :

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 :

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 :

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 :

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 :

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 :

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 :

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]

Envoyé par austin P.

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 :

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 :

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 :

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

Et ainsi de suite...

a++

[austin P.]

Envoyé par adiGuba

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]

Envoyé par adiGuba

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

Envoyé par adiGuba

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]

Envoyé par bobuse

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 :

Buffer flip();

à

Code :

void flip();

doit poser pas mal de problème de compatibilité...

Alors qu'on peut penser que passer à :

Code :

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]

Envoyé par bulbo

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 :

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 :

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]

Envoyé par metalpetsFR

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 :

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

Code :

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]

Envoyé par bulbo

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 :

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]

Envoyé par 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

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.