Problème de polymorphisme

**xSysNeod** · 05/06/2019, 02h43

Bonjour tous le monde.

J'essaie de faire une classe vecteur qui utilise des coordonnées.

La classe Coord est une classe abstraite et générique.
J'ai un problème d'inférence de type semble-t-il.
Je ne comprends pas pourquoi puisque _Coord étend Coord. Il devrait alors être en mesure d'utiliser la méthode.

Voici mes trois classes.

J'espère trouver une solution. Merci beacoup.

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
 
/* PRE_MACRO use CartesianVector2d */
/* LABEL CartesianVector2d 
 *import roomMap.CartesianVector2d;
*/
 
import roomMap.Coord;
import roomMap.Vector;
 
class roomMap {
	/* Run entry */
	public static void main(String[] args){
	/* PRE_MACRO use CartesianVector2d */
	/* LABEL CartesianVector2d
		CartesianVector2d v1 = new CartesianVector2d(2,0);
		CartesianVector2d v2 = new CartesianVector2d(2,4);
		System.out.print(v1);
	*/
 
	Coord<Double> p1;
 
	}
}
 
 
 
package roomMap;
 
public abstract interface Coord<_Number extends Number> {
	public abstract Coord<_Number> getDiffFrom(Coord<_Number> c);
}
 
 
 
 
package roomMap;
 
import roomMap.Coord;
 
public class Vector< _Coord extends Coord<? /*extends Number*/> > {
	private _Coord m_A;	//look if it is pointer :)
	private _Coord m_B;
 
	private _Coord m_direction;	//private setter
 
	Vector (_Coord A, _Coord B) {
		m_A = A;
		m_B = B;
		m_direction = A.getDiffFrom(B); // Le probleme semble etre ici
	}
}

**xSysNeod** · 05/06/2019, 05h05

J'ai aussi essayé avec ce changement dans Coord, au cas ou ca donnerait des idées.

Code :

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

1
2
3
4
5
6
 
package roomMap;
 
public abstract interface Coord<_Number extends Number> {
	public abstract <_Coord extends Coord<_Number> > _Coord getDiffFrom(_Coord c);
}

**Gugelhupf** · 05/06/2019, 11h53

Salut,

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
public interface Coord<N extends Number> {
    Coord<N> getDiffFrom(Coord<N> c);
}
 
public class Vector<N extends Number> {
    private Coord<N> m_A;
    private Coord<N> m_B;
    private Coord<N> m_direction;
 
    Vector (Coord<N> A, Coord<N> B) {
        m_A = A;
        m_B = B;
        m_direction = A.getDiffFrom(B);
    }
}

Note: Le mot-clé abstract est facultatif dans une interface, de même que le mot-clé public pour les méthodes d'une interface. Pense à suivre les conventions Java

A+

**xSysNeod** · 05/06/2019, 12h25

Merci Gugelhupf de la réponse.

Je vais jeter un coup d'oeil sur l'impact du code en changeant la partie générique des Vector et des Point.

Merci de l'information à propos de abstract et public pour les interfaces.

Par pure curiosité, quelqu'un sait pourquoi le code ne fonctionnait pas? Un cast ou un paramètre à passer à javac pour modifier le comportement du linter est possible?

**xSysNeod** · 06/06/2019, 02h32

J'ai trouvé ceci:
http://mail.openjdk.java.net/piperma...ry/008405.html

**thelvin** · 06/06/2019, 10h05

Non, ce n'est pas un bug du jdk, c'est une erreur dans ton code.

Quand tu fais :

Code :

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

1
2
3
public abstract interface Coord<_Number extends Number> {
  public abstract Coord<_Number> getDiffFrom(Coord<_Number> c);
}

Ça peut se réécrire de manière lisible comme ça, c'est la même chose :

Code :

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

1
2
3
public abstract interface Coord<N extends Number> {
  public abstract Coord<N> getDiffFrom(Coord<N> c);
}

On voit que la getDiffFrom() nécessite en paramètre un objet Coord dont le paramétrage est N, c'est-à-dire le même que celui de la classe en cours. En gros, les objets Coord doivent appeler getDiffFrom() sur d'autres objets Coord, dont le typage paramétré doit être le même.

Quand tu fais

Code :

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

public class Vector< _Coord extends Coord<?>> {

qu'on peut réécrire lisiblement

Code :

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

public class Vector<C extends Coord<?>> {

Ça veut dire que le paramètre C est garanti d'être un sous-type de Coord<?>. C'est-à-dire de Coord, dont on ne sait pas trop quel est le paramétrage.

Du coup, avec

Code :

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

1
2
private C m_A;
private C m_B;

Tu te retrouves avec deux variables, dont chacune a un type Coord<?>, c'est-à-dire chacune Coord dont on ne sait pas trop quel est le paramétrage.

Et donc, notamment puisqu'on sait pas trop ce que c'est, on n'a aucune raison de penser que c'est le même paramétrage.

Pas le même paramétrage => on peut pas appeler getDiffFrom() l'un sur l'autre, qui exige le même paramétrage.

**xSysNeod** · 06/06/2019, 13h08

Quand je vais créer un object, je vais dire a java le type. Il me semble bien que Coord<Integer> correspond à Coord<Integer>

**thelvin** · 06/06/2019, 13h54

Le but des génériques c'est de s'assurer que le code que tu tapes, pendant que tu es en train de le taper, utilise bien les bons types.

Genre que tu récupères pas un Integer quand tu demandes une String ou vice-versa.

Ce qui se passe quand ton programme est en train de tourner, donc bien après que tu aies fini de l'écrire et de le compiler, ne concerne donc pas les génériques, mais genre, du tout. En fait on peut dire que les génériques n'existent plus après la compilation.

**xSysNeod** · 06/06/2019, 18h39

Je croyais que les génériques servait à ne pas coder vingt fois la meme fonction

**xSysNeod** · 06/06/2019, 18h47

De plus je croyais que java pouvais faire de l'introspection de type run-time en utilisant des méthodes compilées.

**thelvin** · 07/06/2019, 01h00

Envoyé par xSysNeod

Je croyais que les génériques servait à ne pas coder vingt fois la meme fonction

Ça sert à s'assurer du typage, lorsque tu évites de coder vingt fois la même fonction.
Avant les génériques on pouvait déjà éviter de coder vingt fois la même fonction. Mais les erreurs de typage étaient trop faciles et donc courantes. Les génériques sont là pour régler ça.

Envoyé par xSysNeod

De plus je croyais que java pouvais faire de l'introspection de type run-time en utilisant des méthodes compilées.

Oui. Mais pas avec les génériques.

Je veux dire, l'introspection runtime est capable de te dire qu'une méthode ou une classe qui ont été créées génériques, le sont. Et de quelle manière. Elle peut dire la même chose que ce que tu vois quand tu écris ton programme.

Mais elle ne peut pas dire comment un paramètre générique a été utilisé lorsqu'il est utilisé au runtime.

Les génériques sont un outil de (très grande) aide à la compilation. Et pas après.

**xSysNeod** · 07/06/2019, 21h08

Le problème semble plutôt venir du fait que le linter n'associe pas deux même définitions distinctes (les deux boundaries dans ce cas).
En appuie, le linter se plaint que les cast sont redondants.

Code :

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

1
2
3
4
5
6
 
package roomMap;
 
public abstract interface Coord<_Number extends Number> {
	public abstract <_Coord extends Coord<_Number> > _Coord getDiffFrom(_Coord c);
}

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
 
package roomMap;
 
import roomMap.Coord;
 
public class Vector< _Coord extends Coord<?/* extends Number*/> > {
	private _Coord m_A;	//look if it is pointer :)
	private _Coord m_B;
 
	private _Coord m_direction;	//private setter
 
	Vector (_Coord A, _Coord B) {
		m_A = A;
		m_B = B;
		m_B = A;      //Ici _Coord semble etre _Coord (Même boundary)
		m_A = B;      //Ici _Coord semble etre _Coord (Même boundary)
		m_direction = (_Coord)((_Coord) A).getDiffFrom((_Coord)B);//_Coord Ne semble plus être _Coord à cause du changement de boundary. C'est le linter qui semble être vraiment primitif.
	}
}

**thelvin** · 08/06/2019, 17h16

Envoyé par xSysNeod

Le problème semble plutôt venir du fait que le linter n'associe pas deux même définitions distinctes (les deux boundaries dans ce cas).

Pourquoi "plutôt" ? C'est ce que j'ai dit.

Les deux définitions sont les mêmes, en cela qu'on les obtient de la même manière, et que ça se décrit de la même manière :

"Le paramétrage de ce Coord, on ne sait pas trop bien ce que c'est"

même remarque dans les deux cas, donc même définition.

Mais bien que ce soit la même chose dans les deux cas, ça ne nous dit pas que ces deux définitions sont compatibles quand on a besoin d'associer l'une avec l'autre.
Ce qu'elles ont en commun, c'est qu'on sait pas trop quel est leur paramétrage. Et non pas qu'elles ont le même paramétrage. Or c'est ça que ta méthode exige : deux objets dont le paramétrage est le même.

Bon, on va prendre un cas évident :

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
Coord<Double> c1 = obtenirUnCoordDouble(); // ne cherchons pas à savoir quelle classe a été utilisée pour obtenir ça. Double étend Number, donc on a le droit d'avoir une variable comme ça.
Coord<Integer> c2 = obtenirUnCoordInteger(); // même chose
 
// cet appel est-il autorisé ? Bien sûr que non ! getDiffFrom() ne fait pas de calculs quand l'un des objets est à base de Double et l'autre Integer !
 
Coord<QuelTypeIci> resultat = c1.getDiffFrom(c2);
 
// mais voyons maintenant plus loin :
 
Coord<?> c3 = c1; // on peut faire ça sans problème. c1 est basé sur Double, mais si on préfère perdre cette information dans une autre variable, et retenir qu'on sait pas trop sur quoi se base cette Coord, on peut, aucun souci.
Coord<?> c4 = c2; // même chose
 
// Et donc c3 et c4 déclarent le même typage Coord<?>, bien que les objets vers lesquels elles pointent sont les mêmes que c1 et c2 dont le typage est différent. Pourquoi, parce que ça consiste à dire qu'on sait pas tout sur leur paramétrage.
 
// Et donc peut-on faire ceci:
 
Coord<?> resultat2 = c3.getDiffFrom(c4);
 
// Ben ce serait dommage, puisque c3 et c4 c'est les mêmes objets que c1 et c2, et on a vu pourquoi il est évident que ça ne peut pas marcher.
// résultat des courses, le langage ne peut évidemment pas autoriser à ce que <?> soit considéré comme "le même" qu'un autre <?>. Puisqu'il est si facile de prendre <A> et <B> et de les mettre dans <?> et <?>.

Envoyé par xSysNeod

En appuie, le linter se plaint que les cast sont redondants.

A priori, non. Je ne vois pas bien en quoi tu aurais montré une telle chose.

Bref ce qui se passe, c'est ce que je t'ai dit, ni plus ni moins. Tu pourras toujours dire que c'est ça à la place qui est primitif, si tu as envie. Mais en attendant ça fait le job qui lui est demandé, celui dont on a besoin, ni plus ni moins.
Toi tu exiges de faire des trucs mal définis, tout flous. Il n'y a pas de quoi trouver que les autres font mal leur job.
Si tu veux que tes deux objets soient reconnus comme ayant le même typage, tu choisis un typage clair et précis et tu le donnes aux deux. C'est simple et il suffit de le faire. Va pas trop croire que ton refus de faire ce qui fonctionne et qui est simple, te rend plus malin que les autres.

**xSysNeod** · 10/06/2019, 01h47

Envoyé par thelvin

Pourquoi "plutôt" ? C'est ce que j'ai dit.

Je ne me rappelles pas que tu as parlé des boundaries que le linter se plaignait. J'ai sûrement mal interprété une phrase.

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
 
 
Coord<QuelTypeIci> resultat = c1.getDiffFrom(c2);
 
// mais voyons maintenant plus loin :
 
Coord<?> c3 = c1; // on peut faire ça sans problème. c1 est basé sur Double, mais si on préfère perdre cette information dans une autre variable, et retenir qu'on sait pas trop sur quoi se base cette Coord, on peut, aucun souci.
Coord<?> c4 = c2; // même chose
 
// Et donc peut-on faire ceci:
 
Coord<?> resultat2 = c3.getDiffFrom(c4);
 
// Ben ce serait dommage, puisque c3 et c4 c'est les mêmes objets que c1 et c2, et on a vu pourquoi il est évident que ça ne peut pas marcher.
// résultat des courses, le langage ne peut évidemment pas autoriser à ce que <?> soit considéré comme "le même" qu'un autre <?>. Puisqu'il est si facile de prendre <A> et <B> et de les mettre dans <?> et <?>.
// Et donc c3 et c4 déclarent le même typage Coord<?>, bien que les objets vers lesquels elles pointent sont les mêmes que c1 et c2 dont le typage est différent. Pourquoi, parce que ça consiste à dire qu'on sait pas tout sur leur paramétrage.

Ici sont des déclarations et non des définitions. À moins que ces concepts ne sont pas disjoints en Java (Est-ce le cas). Il me semble que j'ai un problème de définition et non de déclaration.

Envoyé par thelvin

A priori, non. Je ne vois pas bien en quoi tu aurais montré une telle chose.

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
 
javac -Xdiags:verbose -Xlint -d /tmp/src/roomMap/build /tmp/src/roomMap/src/roomMap.java /tmp/src/roomMap/src/roomMap/Coord.java /tmp/src/roomMap/src/roomMap/Vector.java 
/tmp/src/roomMap/src/roomMap/Vector.java:16: warning: [cast] redundant cast to _Coord
		m_direction = (_Coord)((_Coord) A).getDiffFrom((_Coord)B);
		                                               ^
  where _Coord is a type-variable:
    _Coord extends Coord<?> declared in class Vector
/tmp/src/roomMap/src/roomMap/Vector.java:16: warning: [cast] redundant cast to _Coord
		m_direction = (_Coord)((_Coord) A).getDiffFrom((_Coord)B);
		                       ^
  where _Coord is a type-variable:
    _Coord extends Coord<?> declared in class Vector
/tmp/src/roomMap/src/roomMap/Vector.java:16: error: method getDiffFrom in interface Coord<_Number> cannot be applied to given types;
		m_direction = (_Coord)((_Coord) A).getDiffFrom((_Coord)B);
		                                  ^
  required: _Coord#1
  found: _Coord#2
  reason: inferred type does not conform to upper bound(s)
    inferred: _Coord#2
    upper bound(s): Coord<CAP#1>
  where _Coord#1,_Coord#2,_Number are type-variables:
    _Coord#1 extends Coord<CAP#1> declared in method <_Coord#1>getDiffFrom(_Coord#1)
    _Coord#2 extends Coord<?> declared in class Vector
    _Number extends Number declared in interface Coord
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Number from capture of ?
/tmp/src/roomMap/src/roomMap/Vector.java:16: warning: [cast] redundant cast to getDiffFrom
		m_direction = (_Coord)((_Coord) A).getDiffFrom((_Coord)B);
		              ^
1 error
3 warnings

Envoyé par thelvin

Bref ce qui se passe, c'est ce que je t'ai dit, ni plus ni moins.

Tu dis des choses qui touche le typage. C'est évident qu'il y a un problème de typage.

Envoyé par thelvin

Tu pourras toujours dire que c'est ça à la place qui est primitif, si tu as envie. Mais en attendant ça fait le job qui lui est demandé, celui dont on a besoin, ni plus ni moins.
Toi tu exiges de faire des trucs mal définis, tout flous. Il n'y a pas de quoi trouver que les autres font mal leur job.
Si tu veux que tes deux objets soient reconnus comme ayant le même typage, tu choisis un typage clair et précis et tu le donnes aux deux. C'est simple et il suffit de le faire. Va pas trop croire que ton refus de faire ce qui fonctionne et qui est simple, te rend plus malin que les autres.

Si je serais plus malin que les autres je ne serais pas ici à essayer de comprendre
J'ai programmer dans d'autre language ou les "génériques" sont turing-complete. Merci de comprendre que j'essaie d'exploiter Java à son max en espérant retrouver la puissance de d'autre language qui offre de méta programmation (Pense à C++ en autre).

Voici une version du code qui compile encore plus illisible mais fonctionne. Explique moi pourquoi ca compile et je comprendrais pourquoi la version posté ne compile pas. Merci d'avoir pris ton temps pour moi. c'est très apprécier même si nos opinions/interprétations divergent

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
 
package roomMap;
 
public abstract interface Coord<_Number extends Number> {
	public abstract <_Coord extends Coord<? extends Number> > _Coord getDiffFrom(_Coord c);
}
 
 
 
package roomMap;
 
import roomMap.Coord;
 
public class Vector< _Coord extends Coord<?/* extends Number*/> > {
	private _Coord m_A;	//look if it is pointer :)
	private _Coord m_B;
 
	private _Coord m_direction;	//private setter
 
	Vector (_Coord A, _Coord B) {
		m_A = A;
		m_B = B;
		m_direction = A.getDiffFrom(B);
	}
}

Ceci est très mal définit puisque la méthode n'est même plus en relation avec la classe générique. Mais ca compile et fonctionne. Je trouve dégueulasse que ca fonctionne. Le compilo ne se plein même pas du surplus (_Number) créer. WOW.

Tu disais que le langage n'autorise pas un ? à être un autre ?.Je suis mêlé là.

Par contre ici les boundaries sont littérallements identiques.

Un code qui peut planter run-time. Cool ca compile......(c'était du sarcasme là

)
En plus C'est le free for all dans les types maintenant. Les types de la méthode dans Coord sont insignifiants.

**xSysNeod** · 10/06/2019, 01h57

@Gugelhupf

Ta méthode enlève un niveau d'indirection, mais je vais l'utiliser en attendant.

Désolé M. Butler Lampson

**xSysNeod** · 10/06/2019, 02h17

@thelvin

Si tu en as envie (et si tu as le temps).

Je peux t'expliquer l'évolution du premier code écrit.

Ainsi tu comprendras les besoins que j'ai et où je veux m'en aller.

à la fin ca serait utile d'utiliser Vector<PolarCoord2d<Double>> ou encore un Vector<CartesianCoord2d<Integer>>

c'est pour ca qu'il y a une diff abstraite dans Coord.

**xSysNeod** · 10/06/2019, 03h31

En fait je vais coder toute les classes sans utiliser les génériques.

**thelvin** · 10/06/2019, 18h28

En fait je pense qu'à un moment où à un autre, tu te retrouves confronté à un problème de la classe Number : elle ne gère aucun opérateur arithmétique et n'est pas utilisable dans les fonctions mathématiques.

Or pour des coordonnées cartésiennes par exemple, tu te serais retrouvé avec :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class CoordonneeCartesienne<N extends Number> implements Coord<N> {
  private N x;
  private N y;
 
  public CoordonneeCartesienne<N> getDiffFrom(CoordonneeCartesienne<N> c) {
    N resultX = x - c.x; // ouais... Sauf qu'on peut pas utiliser l'opérateur - sur un Number... Ni aucun autre opérateur. Il y a bien le + qui marche mais seulement pour appeler toString() dessus et faire une concaténation
    N resultY = y - c.y;
    return new CoordonneeCartesienne<>(resultX, resultY);
  }
 
}

Number n'ayant pas ce qu'il faut, tu peux pas tout gérer de façon générique, à un moment il faut regarder si le type est Integer, Double ou quelque chose d'autre, et appliquer les fonctions mathématiques adéquates au type trouvé.

Les génériques ne peuvent que t'aider à t'assurer que t'as pas fait de mélange... Et il n'y a pas de moyen d'interdire de construire une CoordonneeCartesienne<Number>, qui du coup a le droit de contenir Integer ou Double ou n'importe quel Number, et donc ont l'impression qu'elles peuvent se mélanger les unes aux autres.