Votre avis sur l'héritage multiple avec JavaFX

salut.

J'ai appris que javafx permettait l'héritage multiple. Je voulais savoir comment elle a résolu les problèmes classiques qui sont liés à cette pratique !

Par exemple, si les deux classes mères contiennent deux méthodes avec le même nom ?

Merci

Ca les resout mal et de maniere pas vraiment bien definie (c'est le flou officiel) dans les versions 1.0 et 1.1/1.1.1*.
La version 1.2 introduit l'usage du mot cle mixin a placer sur les autres classes meres** et permet enfin d'appeler super.nomDeMethodeOuFonction().

**On pouvait heriter d'un nombre infini d'interfaces et de classes JavaFX, le nombre d'heritages de classe Java etait limite a 1 il me semble.

**On ne peut donc heriter d'une seule et unique classe JavaFX et Java directement et d'un nombre infini de mixing JavaFX ou d'interfaces. Le nombre d'heritage de classe Java doit toujours etre limite a 1 vu que le mot cle mixin n'existe pas dans ce language.

Pour le reste, je n'ai pas pousse plus loin mes investigations quant a l'heritage en diamant ou les collisions de nom dans cette nouvelle version (trop de problemes dans les version precedentes font que j'ai vite abandonne le sujet : VIVE LA DELEGATION !).

Exemple :

Code:

---

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

def individual = Contact { firstName: "Julien", lastName: "Jabbot", role: "Senior Developer" }; //~ individual.printInfo(); //~ println(individual.id); (individual as Person).printInfo(); (individual as Employee).printInfo(); println("{(individual as Person).id}"); println("{(individual as Employee).id}");   mixin class Person { var firstName = "Fabien"; var lastName = "Flubbler"; var id = 89771; function printInfo() { println("{firstName} {lastName}"); } abstract function isAlive(); } mixin class Employee { var role = "Project Manager"; var id = 11666342; function printInfo() { println("{role}"); } }   class Contact extends Person, Employee { override function isAlive() { return Person.id > 0; } }

---

On accède au champ ID de chaque mixin, mais pas à la méthode. J'ai rempli un bug : http://javafx-jira.kenai.com/browse/JFXC-3273
Je crois que la solution est qu'un des deux champs sera caché par l'autre...

Comme dit bouye, et comme un peu partout dans JavaFX, c'est pas parfait et en cours d'amélioration...

Ce qui est marrant, c'est qu'on a encore des classes abstraites, qui font maintenant bien double emploi avec les mixins (en plus limité !).

C'est vraiment & evidement le derangement que peut avoir l'heritage simple.
En effet c'est vrai normal qu'un enfant peut heriter de sa mere et son pere d'ailleurs s'il s'agit d'un enfant unique. Supposon que sa mere à un villa au Mali et son pere un autre à Moscone. Je peux bel et bien heriter de ses deux villa.

Mais un probleme persiste, comme il est heritier, les barbes etant public et le sein protected, alors il peut avoir les barbes de son pere et les seins de sa mere.

La on se retrouve devant un autre Michael Jackson. C'est ce qui est frequent en C++.
C'est vrai que ca limite effetictement java mais les interfaces resolvent la plupart de temps ce probleme.

Enfin c'etait juste pour detendre le debat.

Comme mon grand père le disait, si ma tante en avait, l'héritage serait plus simple...

Allez hop, un petit article sur le sujet : http://java.sun.com/developer/techni.../javafx/mixin/


Je comprend tout a fait qu'on ne puisse pas faire cela :

Code:

---

1 2	var m:MyMixin = new MyMixin(); // ILLEGAL. COMPILER ERROR.

---

Mais je suis cependant surpris qu'il ne soit pas possible de faire cela :

Code:

---

1 2 3 4

var m:MyMixin = MyMixin { // ILLEGAL. COMPILER ERROR. variable1: "Hello Again" variable2: "World" }

---

Puisque normalement ceci cree en fait une classes anynome qui etend le mixin.

Ah, bah, JavaFX n'est pas Java (je suppose que tu as remarqué...) et les mixins semblent être un croisement étrange entre interfaces (qui ne peuvent pas être instanciées, et peuvent être combinées) et classes abstraites (qui peuvent être instanciées en fournissant les méthodes manquantes).

Donc cette restriction ne me choque pas (si on se place du côté "interface") mais je comprends ta démarche (du côté "classe abstraite").

Je ne suis pas fana du concept des classes anonymes en Java, c'est sans doute pour ça que je n'ai jamais pensé à essayer ça...

Faudrait que je revérifie (voir plus bas) mais il me semble qu'on peut tout instancier de cette manière en JavaFX SAUF les mixins donc je vois pas pourquoi on ne peut pas faire ainsi. Rappel il ne s'agit pas d'une simple instanciation mais de la création d'une classe concrète anynome et donc c'est plutot stupide de ne pas permettre de le faire sur des mixin.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.AbstractAction;   // Interface. def actionListener:ActionListener = ActionListener { public override function actionPerformed(e:ActionEvent):Void { } } // Classe abstraite. def action:AbstractAction = AbstractAction { public override function actionPerformed(e:ActionEvent):Void { } }

---

Ps : tu dis ne pas être fana du concep... mais ON NE FAIT QUE CELA (ou presque) en JavaFX. En gros, on crée des classes anonymes dès qu'on ouvre une paire d'acollade (et j'exagère à peine, va jeter un coup d'oeil devant la foison de classes anonymes produites par la compilation).

Tu peux instancier des classes abstraites, bien sûr, mais pas des interfaces. Si les concepteurs voient les mixins comme ces dernières, ils interdisent leur instanciation. Soit c'est volontaire pour cette raison, soit il y a problème technique interdisant cette opération, soit ils n'y ont simplement pas pensé. Dans ce dernier cas, rien n'empêche un petit saut à Jira pour le suggérer... :-)

Classes anonymes en JavaFX : c'est vrai, mais elles sont "cachées", on s'en fiche. Ce qui m'ennuie avec elles en Java, c'est qu'on créée une classe seulement pour enrober une petite fonction, et la syntaxe est lourde. Au moins, en JavaFX, on peut assigner une fonction directement, c'est plus proche de JavaScript et autres langages dynamiques.

Euh as-tu au moins lu le code que j'ai poste ? :aie:

Doh ! Que d'un œil, probablement endormi, j'en ai peur.
Désolé.
En fait, je crois avoir confondu ActionListener (une interface) avec MouseAdapter (une classe abstraite avec des méthodes concretes...) ou je ne sais quoi. Bref, je me suis planté, mais cela gravera la leçon dans ma mémoire... :-P

Tiens, j'ai fait une expérimentation amusante... J'ai réutilisé mon mixin :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

mixin class Person { var firstName = "Fabien"; var lastName = "Flubbler"; var id = 89771; function printInfo() { println("{firstName} {lastName}"); } abstract function isAlive(): Boolean; }

---

J'ai viré la définition de fonction abstraite, et j'ai essayé de faire comme toi :

Code:

---

1 2 3 4 5

var p: Person = Person { firstName: "Bar" } println(p.firstName);

---

Paf ! Comme toi, j'ai un beau message : "Person is a mixin; cannot be instantiated."
OK, maintenant, je remet la fonction abstraite, et j'essaie :

Code:

---

1 2 3 4 5 6

var p: Person = Person { override function isAlive(): Boolean { return id > 0; } firstName: "Doh" var somethingElse = 42; }

---

Et ça compile et tourne sans problème... :-)

Hum c'est un peu LoL-esque en effet... il doit y avoir des effets sur le bytecode ou le nombre de classes intermediaires produites pour lesquels nous ne sommes pas au courant.

Bah on verra ce que ca donnera dans la prochaine version. More fun ahead !