Discussion :

[genova]

Salut,
malheureusement dans ta solution ThomasR Article et JobRecursif ne peuvent pas vraiment communiquer directement, à moins de créer sans arrêt des accesseurs. De plus : exit la surcharge de méthodes

J'ai lu un peu les specifications des traits, et ça a l'air assez interessant. Peut être pour PHP7, dans un futur lointain

[ThomasR]

Salut,
malheureusement dans ta solution ThomasR Article et JobRecursif ne peuvent pas vraiment communiquer directement, à moins de créer sans arrêt des accesseurs. De plus : exit la surcharge de méthodes

Si tu appelles communiquer directement le fait de pouvoir appeler les méthodes de JobRecursif sans devoir passer un membre, oui :p

J'ai lu un peu les specifications des traits, et ça a l'air assez interessant. Peut être pour PHP7, dans un futur lointain

Je trouve çà aussi très interessant mais j'irais pas jusqu'à l'implémenter dans PHP pour pallier au problème d'héritage multiple puisque le concept n'apporte aucune notion d'héritage.

Traits are an alternative which have been designed to impose no additional semantics on classes. Traits are only entities of the literal
code written in your source files. There is no notion about Traits at runtime.
They are used to group methods and reuse code and are totally flattened into the classes composed from them. It is almost like a language supported and failsafe copy'n'paste mechanism to build classes.

Le principe serait apparement un méchanisme de copie-collage.

J'éspère qu'ils vont réellement implémenter l'héritage multiple car c'est vraiment un besoin (comme ton exemple le démontre si bien).

[goodpz]

Avec les traits et les interfaces, on arrive à quelque chose de très proche du multiple héritage. Ceci est extrait du proposal sur les traits (voir posts précédents) :

Traits are interfaces with implementation

J'éspère qu'ils vont réellement implémenter l'héritage multiple car c'est vraiment un besoin

Ce n'est pas demain la veille que l'héritage multiple sera implémenté dans php.

[mon_nom_est_personne]

je pense que l'heritage multiple sera implementer le jour ou php sera compiler ou alors partiellement compiler a la java. Mais c'est vrai que les dernieres articles theorique de la programmation parle de plus en plus de POO (le dernier pour Ontologie) comme decrit dans http://www.w3.org/TR/sw-oosd-primer/.
C'est un peu un vieille article mais ca donne des idees.
comme l'a si bien dit genova, "peut-etre pour php 7"

[ThomasR]

Avec les traits et les interfaces, on arrive à quelque chose de très proche du multiple héritage

D'un point de vue conceptuel, pas du tout.

Traits are interfaces with implementation

Comme expliqué dans mon post précédent, cela n'est qu'un méchanisme de copy collage très performant.

[GrandFather]

Les développeurs Java ne disposent pas de l'héritage multiple, et ça ne les empêche pas de produire des librairies ou des frameworks considérables et d'une excellente qualité en terme de génie logiciel.

Dans ton exposé, Genova, il y a quelque chose que je ne saisis pas : pourquoi vouloir absolument faire rentrer JobRecursif et JobDynamique dans l'arbre d'héritage des descendants de Job, alors qu'a priori le polymorphisme (passer une instance de classe dérivée là où est attendue une instance de classe ancêtre) n'est pas exploité ? Pourquoi ne pas simplement utiliser la composition et la délégation, en créant deux variables membres recursif et dynamique dans la classe Article, et en les initialisant dans le constructeur, en lui passant une instance de JobRecursif et une de JobDynamique en paramètres ?

Ca ne simplifiera pas forcément le code, mais l'héritage multiple ne simplifie pas toujours les choses, les développeurs C++ peuvent en parler, et eux ont au moins la chance de disposer d'un compilateur qui peut détecter préventivement certains problèmes... La vraie simplification passerait, je suis totalement d'accord avec goodpz, par les traits, qui ressemblent fortement (sans être équivalents) aux Mixins de Ruby qui sont prévus justement pour remplacer l'héritage multiple.