Discussion :

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

[Uther]

Moi This ne me dérange plus que this car il s'agit justement pas d'une classe mais d'un mot clé qui indique que la classe retournée varie en fonction de l'héritage.
Or en java tous les mots clés commencent par une minuscule. Ceci dit je pense que un nouveau mot clé comme selfclass serait plus clair que this qui a déjà une signification assez différente.

[adiGuba]

Moi je vois deux sens différents pour This et this


This retournerais le même type, mais pas forcément l'instance courante, typiquement :

Code :

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

1
2
3
4
5
6
7
	public This clone() {
		return super.clone();
	}
 
	public This get() {
		return getClass().newInstance();
	}

(même si je ne sais pas si c'est évident à vérifier pour le compilateur)



Tandis que this obligerait à retourner this, donc l'instance courante :

Code :

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

1
2
3
4
public this setValue(String value) {
    this.value = value;
    return this; // qui pourrait d'ailleurs être optionnel
}

(ce qui permet de faire du chainage proprement)


a++

[divxdede]

Même si aujourd'hui ce n'est pas idéal, on peut déja "simuler" une covariance automatique sans redefinir les méthodes.

Pour ca faut passer par la généricité comme suit:

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/**
 * Classe Mere utilisant la généricité pour indiquer son "propre" type
 * Afin d'automatiser une "sorte" de covariance
 *
 * @author André Sébastien
 */
public class ClasseMere<E extends ClasseMere>  {
 
    /** Creates a new instance of ClasseMere */
    public ClasseMere() {
 
        /** Je peu appeller la méthode "mere" sans CAST
         *  De plus l'éditeur (Netbeans) me propose bien la complétion (mais dit type E)
         */
        get().mere();
    }
 
    /** Méthode automatiquement "covariée" en utilisant la généricité... (what a hell ?)
     */
    public E get() {
        return (E)this;
    }
 
    /** Méthode spécifique à ClasseMere
     */    
    public void mere() {
        System.out.println("Méthode d'une classe mère");
    }
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        new ClasseMere();
    }
}

Avec une classe fille comme suit:

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/**
 * Classe fille dérivant de sa classe mére en adaptant la covariance automatiquement a son propre type
 *  - Ne redefinit pas "get()" 
 *
 * @author André Sébastien
 */
public class ClasseFille extends ClasseMere<ClasseFille> {
 
    /** Creates a new instance of ClasseFille */
    public ClasseFille() {
 
        /** Je peu appeller la méthode "fille" sans CAST
         *  De plus l'éditeur (Netbeans) me propose bien la complétion
         */
        get().fille();
    }
 
    /** Méthode spécifique à ClasseFille
     */
    public void fille() {
        System.out.println("Méthode de la classe fille");
    }
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        new ClasseFille();
    }    
}

Je sais que ce n'est pas spécialement idéale mais on peut donc malgrés tout déja formaliser le

Code :

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

   public This get();

PS: Je suis ni pour ni contre la proposition en soit.

[adiGuba]

Oui... sans que c'est lourd et qu'il faut toujours se trimballer les Generics "inutilement".

D'ailleurs la classe fille devrait plutôt être déclaré comme ceci :

Code :

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

public class ClasseFille<E> extends ClasseMere<E extends ClasseFille> {

Afin qu'elle puisse aussi avoir une classe fille...


a++

[TPReal]

Avec tout ce code overhead, c'est plus facile a projeter les types manuellement maintenant.

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

[ptitbob]

Bonjour,

J'ai voté pour la proposition 1... Mais je sens que cela va être plutôt une source de confusion... Le transtypage permet effectivement un meilleur contrôle de ce que l'on code.

Cdlt

[lex2004]

D'accord avec la première proposition. Elle va dans le même ordre d'idées que l'appel de constructeur this() qui évite avantageusement de répéter le nom de 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é.