Mixins, plugins...un peu perdin

Bonjour !

- de classes Mixins ;

Je ne suis pas sûr de bien comprendre. Avec Python, à quoi serviraient
des classes mixin ? Ne suffit-il pas de créer une super-classe, dont
on ferait hériter les classes qui en ont besoin ? Vu que l'héritage
multiple existe dans Python, c'est un moyen facile d'ajouter des
méthodes.

Sinon, on peut aussi ajouter des méthodes à une classe quelconque.

- de plugins pour une application quelconque, sans utiliser de
solution tierces (egg, autres);

Là je décroche. Des plugins "pour une application quelconque" ça semble
trop universel pour être crédible/possible.

Peut-être que quelques explications complémentaires...







--
@-salutations

Michel Claveau

On 21 mai, 15:07, MCI, Shadok Gouroudoudou <pas...@spam.svp> wrote:

Bonjour !

- de classes Mixins ;

Je ne suis pas sûr de bien comprendre. Avec Python, à quoi serviraient
des classes mixin ? Ne suffit-il pas de créer une super-classe, dont
on ferait hériter les classes qui en ont besoin ? Vu que l'héritage
multiple existe dans Python, c'est un moyen facile d'ajouter des
méthodes.

Sinon, on peut aussi ajouter des méthodes à une classe quelconque.

- de plugins pour une application quelconque, sans utiliser de
solution tierces (egg, autres);

Là je décroche. Des plugins "pour une application quelconque" ça se mble
trop universel pour être crédible/possible.

Peut-être que quelques explications complémentaires...

--
@-salutations

Michel Claveau

Bonjour Michel,

pour les Mixins, je pensais par exemple à ceci :

http://sebulba.wikispaces.com/recipe+real+mixins

quelques explications supplémentaire ici :
http://sebulba.wikispaces.com/recipe+module+mixins

En ce qui concerne les plugins, comment font les autres dans une
application avec GUI par exemple ?
J'aimerai ne pas avoir à joueur avec des __import__(), mais ça me
semble un peu difficile.

On 21 mai, 15:07, MCI, Shadok Gouroudoudou <pas...@spam.svp> wrote:

pour les Mixins, je pensais par exemple à ceci :

http://sebulba.wikispaces.com/recipe+real+mixins

bouah, c'est trop horrible, faut tout arrêter à ce stade. La solution
proposée ne présente aucun intéret que de s'embarasser de problème qu'on
a pas avec l'héritage multiple. En plus elle ne dit pas son nom, c'est
du monkey patch déguisé, et le monkey patch n'a pas vocation à résoudre
des problèmes de conception.

Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très vilain,
on verrait tout de suite qu'on ne fait que patcher la classe.

class Foo(object):
...

... def h(self):
... print "h"

mixin(Foo, SomeMixin)
mixin(Foo, AnotherMixin)

Mais sérieusement, qui voudrait sérieusement écrire une hiérarchie de
classe comme celle-là ?

On peut jouer avec les définitions partielles de classe en Python, ce
qui revient un peu au même mais qui a vocation à résoudre un problème
précis (il y a plusieurs article là-dessus dans le cookbook et il me
vient au moins une implémentation évidente et très simple), mais
j'admets ne pas voir beaucoup l'intérêt dans des cas concret (une classe
qui serait si grosse que sa définition ne tient pas dans un fichier,
c'est selon moi une classe qui a un problème...).

Le bonne façon de concevoir/implémenter les mixins en python c'est
l'exemple donné par la classe DictMixin du module UserDict, et
d'utiliser l'héritage multiple.

Si on veut vraiment éviter l'héritage, la seule alternative à qui soit
propre c'est d'utiliser un wrapper, pour une instance préexistante par
exemple, dont le rôle et d'adapter l'objet à l'interface attendue (par
une fonction).

quelques explications supplémentaire ici :
http://sebulba.wikispaces.com/recipe+module+mixins

De mieux en mieux, il ne faut pas chercher à retranscrire ce qu'on
trouve ailleurs tel quel (c'est aussi ce genre de choses qui me font
dire que Ruby n'est pas un langage encore très stable/mature dans sa
conception, et qu'il vaut mieux avoir un héritage multiple consistent à
la Python que d'avoir à faire des trucs dans le genre).

En ce qui concerne les plugins, comment font les autres dans une
application avec GUI par exemple ?

J'aimerai ne pas avoir à joueur avec des __import__(), mais ça me
semble un peu difficile.

Pourquoi pas ? C'est la seule manière d'importer un module dont on
connait le nom qu'à l'exécution (sous forme de chaîne), et cela n'a rien
de "sale" (à la différence de l'horrible mixin proposé plus haut).

Ensuite vos plugins auront besoin de s'enregistrer auprès de
l'application, si on veut écrire les plugins sous forme de classes non
instanciables, ce qui est assez élégant comparé à un contructeur à
rallonge, une solution simple et très propre est d'utiliser les métaclasses.

Maric,

je n'ai prétendu que l'implémentation que j'avais trouvée sur le site
précédent était proprement codée.
Tu parles du cookbook, c'est justement là que je l'ai trouvée(les 2
premiers résultats en cherchant "mixins").
Qu'as-tu de plus "propre" sur le cookbook ?

De même, sur les plugins j'aurai volontiers voulu voir un exemple. Des
liens, quelque chose de concret que je puisse y mettre le nez quoi.

Merci.

On 21 mai, 15:07, MCI, Shadok Gouroudoudou <pas...@spam.svp> wrote:

pour les Mixins, je pensais par exemple à ceci :

http://sebulba.wikispaces.com/recipe+real+mixins

bouah, c'est trop horrible,

Ah bon ? Pourquoi donc ?

faut tout arrêter à ce stade. La solution
proposée ne présente aucun intéret que de s'embarasser de problème qu'on
a pas avec l'héritage multiple.

Hmm... Il faudrait probablement réfléchir plus que je ne l'ai fait pour
le moment aux avantages et inconvénients comparés des deux solutions,
mais le fait est que l'héritage multiple n'a pas non plus que des
avantages. Ceux qui ont un peu hacké Zope2 en savent quelque chose...

En plus elle ne dit pas son nom, c'est
du monkey patch déguisé,

Je dirais plutôt "encapsulé" que "déguisé".

et le monkey patch n'a pas vocation à résoudre
des problèmes de conception.

Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très vilain,

Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?

Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ? Attention, je ne dis pas qu'il faille
systématiquement utiliser les possibilités les plus avancées, mais de là
à cataloguer de la sorte toute utilisation d'un module qui fait partie
de la bibliothèque standard, c'est peu être un poil expéditif. J'utilise
souvent inspect, et occasionnellement le monkeypatching, et d'une
manière générale le résultat est nettement moins vilain que si je ne le
faisais pas.

(snip)

Le bonne façon de concevoir/implémenter les mixins en python c'est
l'exemple donné par la classe DictMixin du module UserDict, et
d'utiliser l'héritage multiple.

C'est *une* façon, pas "la bonne" façon.

Si on veut vraiment éviter l'héritage, la seule alternative à qui soit
propre c'est d'utiliser un wrapper, pour une instance préexistante par
exemple, dont le rôle et d'adapter l'objet à l'interface attendue (par
une fonction).

En quoi le fait de patcher une classe/un objet est-il sale ? C'est très
souvent une solution plus simple, plus efficace, et plus robuste que le
pattern décorateur - lequel, comme pas mal d'autres, existe en partie du
fait du manque de dynamisme de certains langages.

quelques explications supplémentaire ici :
http://sebulba.wikispaces.com/recipe+module+mixins

De mieux en mieux, il ne faut pas chercher à retranscrire ce qu'on
trouve ailleurs tel quel (c'est aussi ce genre de choses qui me font
dire que Ruby n'est pas un langage encore très stable/mature dans sa
conception, et qu'il vaut mieux avoir un héritage multiple consistent à
la Python que d'avoir à faire des trucs dans le genre).

Il ne faut peut-être pas non plus juger les solutions d'un langage
d'après le concepts d'un autre langage ? Les modules mixin de Ruby
répondent à la grande majorité des cas d'utilisation de l'héritage
multiple tout en faisant l'économie des complexités de cette dernière.
C'est un choix de conception délibéré, et ce n'est certainement pas AMHA
le plus mauvais. S'il est évident que Ruby souffre encore de quelques
défauts de jeunesse, ils sont pour l'essentiel du côté de l'implémentation.

Mes deux centimes...

Maric,

je n'ai prétendu que l'implémentation que j'avais trouvée sur le site
précédent était proprement codée.

Je n'ai jamais prétendu que tu avais prétendu cela...

Tu parles du cookbook, c'est justement là que je l'ai trouvée(les 2
premiers résultats en cherchant "mixins").
Qu'as-tu de plus "propre" sur le cookbook ?

Ben sur les mixins je sais pas, le bon exemple de mixin en Python c'est,
je crois, celui donné par DictMixin comme je l'ai indiqué, et cela
utilise l'héritage.

On 21 mai, 15:07, MCI, Shadok Gouroudoudou <pas...@spam.svp> wrote:

pour les Mixins, je pensais par exemple à ceci :

http://sebulba.wikispaces.com/recipe+real+mixins

bouah, c'est trop horrible,

Ah bon ? Pourquoi donc ?

faut tout arrêter à ce stade. La solution proposée ne présente aucun
intéret que de s'embarasser de problème qu'on a pas avec l'héritage
multiple.

Hmm... Il faudrait probablement réfléchir plus que je ne l'ai fait pour
le moment aux avantages et inconvénients comparés des deux solutions,
mais le fait est que l'héritage multiple n'a pas non plus que des
avantages. Ceux qui ont un peu hacké Zope2 en savent quelque chose...

Mais bon, pour être clair, quel est l'interet de la méthode ?

Recopier dans chaque classe les méthodes d'une autre ?
C'est justement pour éviter cela qu'on a inventé l'héritage. Et puis
comment on gère les collisions de nom avec cette technique ?
C'est la notation ? Non, sérieux.

Franchement remplacer l'héritage pour ça c'est comme se tirer une balle
dans le pied.

L'héritage est fait pour ça, hériter du comportement d'une autre classe.
La seule autre relation connue, d'un point de vue POO, entre deux
objets c'est l'agrégation (les interfaces c'est de l'héritage, et il n'y
a qu'en Java qu'on considère leur déclaration systématique come la
règle, je ne parle pas non plus des classes génériques, qui relève
d'autre chose).

Hmm, mais j'ai l'impression qu'on a déjà eu cette discussion, Bruno, sur
c.l.py, mais bon en anglais c'est moins facile (pour moi).

En plus elle ne dit pas son nom, c'est du monkey patch déguisé,

Je dirais plutôt "encapsulé" que "déguisé".

et le monkey patch n'a pas vocation à résoudre des problèmes de
conception.

Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très vilain,

Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?

Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ? Attention, je ne dis pas qu'il faille
systématiquement utiliser les possibilités les plus avancées, mais de là
à cataloguer de la sorte toute utilisation d'un module qui fait partie
de la bibliothèque standard, c'est peu être un poil expéditif. J'utilise
souvent inspect, et occasionnellement le monkeypatching, et d'une
manière générale le résultat est nettement moins vilain que si je ne le
faisais pas.

inspect c'est bien, super, c'est pour ces possibilité là que Pÿthon (en
tant que langage à typage dynamique) est de loin supérieur à Java,
disons. Le rôle d'inspect c'est de permettre au programmeur de
travailler sur les frame, de naviguer dans la pile etc. C'est génial
pour écrire toute sorte de chose qui travailler avec le flot d'exécution
d'un programme.
Quand on s'en sert pour résoudre des problèmes de conception, j'ai un
doute, j'aurai tendance à penser que le problème est mal posé au départ
où la solution un peu trop tordu.


Concernant le monkey patching, je ne le condamne pas, au contraire,
c'est un outil que j'utilise très souvent avec beaucoup de plaisir, et
qui, a contrario de ce que l'on pourrait croire quand on vient de la
programmation "statique", est parfaitement sûr.

Son but ? Surcharger le comportement d'un objet existant et sur lequel
on a pas le contrôle. L'utiliser pour *définir* est donc a priori
inaproprié et très certainement tiré par les cheveux.

quelques explications supplémentaire ici :
http://sebulba.wikispaces.com/recipe+module+mixins

De mieux en mieux, il ne faut pas chercher à retranscrire ce qu'on
trouve ailleurs tel quel (c'est aussi ce genre de choses qui me font
dire que Ruby n'est pas un langage encore très stable/mature dans sa
conception, et qu'il vaut mieux avoir un héritage multiple consistent
à la Python que d'avoir à faire des trucs dans le genre).

Il ne faut peut-être pas non plus juger les solutions d'un langage
d'après le concepts d'un autre langage ? Les modules mixin de Ruby
répondent à la grande majorité des cas d'utilisation de l'héritage
multiple tout en faisant l'économie des complexités de cette dernière.
C'est un choix de conception délibéré, et ce n'est certainement pas AMHA
le plus mauvais. S'il est évident que Ruby souffre encore de quelques
défauts de jeunesse, ils sont pour l'essentiel du côté de
l'implémentation.

Je veux pas cracher sur Ruby, je connais pas très bien. Si sa conception
manque de maturité, c'est plus une impression que j'ai à chaque fois que
je suis les discussions sur le sujet.
J'ai tendance à penser que c'est un peu fourre-tout, leur façon
d'ajouter des nouvelles fonctionnalités au language, à la différence de
ce qui se passe avec Python, qui a beaucoup évolué lui aussi avec les
dernières versions, mais toujurs dans le sens d'une plus grande
cohérence générale, d'une unification des différentes solutions
existantes. Alors qu'avec Ruby, quand j'ai suivi un tutoriel, à chaque
chapître j'avais l'impression de découvrir une nouvelle façon de faire
ce que j'avais appris à faire trois chapîtres plus tôt.

En revanche je suis pas d'accord avec le choix de Ruby et Java de jeter
l'héritage multiple. C'est pas parce qu'une méthode peut être mal
utilisée qu'on doit la supprimer et chercher des paliatifs.


Je développe beaucoup sur Zope2, et c'est pas l'héritage multiple qui
est en question dans Zope2 (enfin je vois pas un seul problème concret
qui pourrait faire dire cela, des liens ?), mais sa mauvaise
utilisation. De toute façon la conception interne de Zope ne respecte
pas un des principe même du zen de Python "flat is better, than nested".
C'est la multiplication des classes et leur imbrication qui est
problématique et l'utilisation de l'héritage systématique alors que
d'autres techniques existent et seraient plus apropriées.

Du reste, je suis pas fan des solutions proposées dans la conception de
Zope3 : interfaces à la Java, Zcml, ..., tout ça ça fait très "mode"
J2EE et cela rapproche fatalement Zope de la lourdeur de J2EE.

Mes deux centimes...

Les miens aussi.

Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très vilain,

Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?

Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ?

Euh, il s'agit pas vraiment d'un dogme, c'est juste que quand on utilise
pas un outil pour ce pourquoi il est prévu c'est louche.

Mais voilà ! je me souviens d'un exemple d'une utilisation d'inspect
pour créer des /properties/ à partir de décorateurs, c'était assez élégant.
Mais dans les deux cas c'est pour contourner une limitation du langage
concernant la notation, et je ne pense pas qu'on puisse tabler sur le
fait que cette solution soit pérenne (si il y a vraiment un problème
avec la notation une solution viendra du langage elle-même), c'est pour
ça que j'ai certaines réticences a utiliser ces solutions.

Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très vilain,

Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?

Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ?

Euh, il s'agit pas vraiment d'un dogme, c'est juste que quand on utilise
pas un outil pour ce pourquoi il est prévu c'est louche.

Ou créatif. Selon...

Mais voilà ! je me souviens d'un exemple d'une utilisation d'inspect
pour créer des /properties/ à partir de décorateurs, c'était assez élégant.
Mais dans les deux cas c'est pour contourner une limitation du langage
concernant la notation, et je ne pense pas qu'on puisse tabler sur le
fait que cette solution soit pérenne (si il y a vraiment un problème
avec la notation une solution viendra du langage elle-même),

Mmm... Peut-être, peut-être pas, et en attendant il est plus agréable
d'avoir une solution que de ne pas en avoir...

Personnellement, ça ne me dérange pas de détourner une fonctionnalité de
sa vocation première si cela permet d'exprimer plus simplement et plus
élégamment certaines choses - je pense entre autres à la technique
employée dans l'exemple de l'OP (même si je suis sur le fond d'accord
avec toi que ce n'est pas forcément la meilleure solution au problème en
l'occurrence), technique qu'on retrouve également dans les systèmes
d'interfaces de Zope3 et de Trac, et dans les 'statements' de Elixir.
Dans un même genre, il y a aussi l'utilisation que faisait la partie DB
de Trac de __getitem_ pour définir un minilangage de définition de
données.

(snip)

On 21 mai, 15:07, MCI, Shadok Gouroudoudou <pas...@spam.svp> wrote:

pour les Mixins, je pensais par exemple à ceci :

http://sebulba.wikispaces.com/recipe+real+mixins

bouah, c'est trop horrible,

Ah bon ? Pourquoi donc ?

faut tout arrêter à ce stade. La solution proposée ne présente aucun
intéret que de s'embarasser de problème qu'on a pas avec l'héritage
multiple.

Hmm... Il faudrait probablement réfléchir plus que je ne l'ai fait pour
le moment aux avantages et inconvénients comparés des deux solutions,
mais le fait est que l'héritage multiple n'a pas non plus que des
avantages. Ceux qui ont un peu hacké Zope2 en savent quelque chose...

Mais bon, pour être clair, quel est l'interet de la méthode ?

Recopier dans chaque classe les méthodes d'une autre ?

Ce n'est pas une recopie, c'est une injection.

C'est justement pour éviter cela qu'on a inventé l'héritage. Et puis
comment on gère les collisions de nom avec cette technique ?
C'est la notation ? Non, sérieux.

Franchement remplacer l'héritage pour ça c'est comme se tirer une balle
dans le pied.

Gérer correctement l'héritage multiple n'est pas non plus toujours une
partie de plaisir. Mais honnêtement, je réagissais surtout (et en me
faisant quelque peu l'avocat du diable, je l'avoue) au côté un peu
absolu de tes propos. Personnellement, quand je vois une solution à
laquelle je n'avais pas pensé avant, j'aime bien prendre le temps de
l'étudier, ne serait-ce que pour voir ce qu'il y a à en apprendre. Dans
ce cas précis, et sur le fond, il faudrais que je me penche un peu plus
sur la question pour avoir un avis sur les avantages et inconvénients de
la solution.

L'héritage est fait pour ça, hériter du comportement d'une autre classe.
La seule autre relation connue, d'un point de vue POO, entre deux
objets c'est l'agrégation

Non. Il y a aussi - officiellement - la relation et la composition.

(snip)

Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très vilain,

Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?

Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ? Attention, je ne dis pas qu'il faille
systématiquement utiliser les possibilités les plus avancées, mais de là
à cataloguer de la sorte toute utilisation d'un module qui fait partie
de la bibliothèque standard, c'est peu être un poil expéditif. J'utilise
souvent inspect, et occasionnellement le monkeypatching, et d'une
manière générale le résultat est nettement moins vilain que si je ne le
faisais pas.

inspect c'est bien, super, c'est pour ces possibilité là que Pÿthon (en
tant que langage à typage dynamique)

Tu peux laisser de côté le 'à typage', AMHA - il n'y a pas que ça de
dynamique en Python.

est de loin supérieur à Java,
disons. Le rôle d'inspect c'est de permettre au programmeur de
travailler sur les frame, de naviguer dans la pile etc.

Pas uniquement. Dans un framework mvc sauce web, c'est une bonne façon
de passer au controleur les arguments de la requête - ce qui évite au
développeur du contrôleur d'avoir à le faire. En ce qui me concerne,
j'aime bien factoriser tout ce qui peut l'être.

Quand on s'en sert pour résoudre des problèmes de conception, j'ai un
doute, j'aurai tendance à penser que le problème est mal posé au départ
où la solution un peu trop tordu.

Penser que la conception puisse être totalement découplée de
l'implémentation est AMHA un mythe.

Concernant le monkey patching, je ne le condamne pas, au contraire,
c'est un outil que j'utilise très souvent avec beaucoup de plaisir, et
qui, a contrario de ce que l'on pourrait croire quand on vient de la
programmation "statique", est parfaitement sûr.

Son but ? Surcharger le comportement d'un objet existant et sur lequel
on a pas le contrôle. L'utiliser pour *définir* est donc a priori
inaproprié et très certainement tiré par les cheveux.

Mmm... Que ce soit une approche un peu latérale, j'en conviens. De là à
la rejeter d'office, il y a un pas que je m'empresse de ne pas franchir.

(snip)

il ne faut pas chercher à retranscrire ce qu'on
trouve ailleurs tel quel (c'est aussi ce genre de choses qui me font
dire que Ruby n'est pas un langage encore très stable/mature dans sa
conception, et qu'il vaut mieux avoir un héritage multiple consistent
à la Python que d'avoir à faire des trucs dans le genre).

Il ne faut peut-être pas non plus juger les solutions d'un langage
d'après le concepts d'un autre langage ? Les modules mixin de Ruby
répondent à la grande majorité des cas d'utilisation de l'héritage
multiple tout en faisant l'économie des complexités de cette dernière.
C'est un choix de conception délibéré, et ce n'est certainement pas AMHA
le plus mauvais. S'il est évident que Ruby souffre encore de quelques
défauts de jeunesse, ils sont pour l'essentiel du côté de
l'implémentation.

Je veux pas cracher sur Ruby, je connais pas très bien. Si sa conception
manque de maturité, c'est plus une impression que j'ai à chaque fois que
je suis les discussions sur le sujet.
J'ai tendance à penser que c'est un peu fourre-tout, leur façon
d'ajouter des nouvelles fonctionnalités au language, à la différence de
ce qui se passe avec Python, qui a beaucoup évolué lui aussi avec les
dernières versions, mais toujurs dans le sens d'une plus grande
cohérence générale, d'une unification des différentes solutions
existantes. Alors qu'avec Ruby, quand j'ai suivi un tutoriel, à chaque
chapître j'avais l'impression de découvrir une nouvelle façon de faire
ce que j'avais appris à faire trois chapîtres plus tôt.

Il n'y a pas que dans les dernières versions que Python a beaucoup
évolué. Et une bonne part de ces évolutions n'étaient pas un luxe, loin
s'en faut. Ruby part avec un modèle objet bien plus cohérent et complet
que ne l'était celui de Python il y a quelques années, et des
possibilités dont je regrette qu'elles n'existent pas en Python. Il y a
effectivement une nette différence philosophique entre Python et Ruby
concernant les différentes façons possible de dépiauter un chat, mais
dans la pratique Ruby tend à se fédérer autour de certains idiomes
dominants alors que Python s'est - historiquement - un peu éparpillé.

En revanche je suis pas d'accord avec le choix de Ruby et Java de jeter
l'héritage multiple. C'est pas parce qu'une méthode peut être mal
utilisée qu'on doit la supprimer et chercher des paliatifs.

Je ne me prononcerai pas sur Java - d'une part pour éviter un troll,
d'autre part parce que le rôle de l'héritage - et particulièrement de
l'héritage multiple - est très différent dans un langage à typage
statique déclaratif. En ce qui concerne le choix fait par Ruby, il
répond à une écrasante majorité des cas d'utilisation que j'ai eu de
l'héritage multiple dans Python. C'est donc, en ce qui me concerne, une
bonne solution.

Je développe beaucoup sur Zope2, et c'est pas l'héritage multiple qui
est en question dans Zope2 (enfin je vois pas un seul problème concret
qui pourrait faire dire cela, des liens ?),

Non, l'expérience seulement.

mais sa mauvaise
utilisation. De toute façon la conception interne de Zope ne respecte
pas un des principe même du zen de Python "flat is better, than nested".
C'est la multiplication des classes et leur imbrication qui est
problématique et l'utilisation de l'héritage systématique alors que
d'autres techniques existent et seraient plus apropriées.

<aol />

Du reste, je suis pas fan des solutions proposées dans la conception de
Zope3 : interfaces à la Java,

Là je t'arrête. Le système d'interfaces de Zope3 est sans grand rapport
avec celui de Java. Il ne s'agit pas en l'occurrence de pallier à
l'absence d'héritage multiple dans un langage dans lequel le typage
conditionne le polymorphisme, mais surtout de permettre d'adapter
dynamiquement diverses interfaces les unes aux autres. Même si le
résultat final est bien trop usineàgazesque pour mon goût, il y a AMHA
quelque chose de très intéressant qui se dessine de ce côté là - voire
aussi à ce propos les modules dispatch et protocol de Peak, et certaines
réflexions du BDFL sur les mérites comparés des deux approches et la
possibilité de faire se rejoindre (il faudrait que je retrouve l'url de
cette discussion d'ailleurs)

Zcml, ..., tout ça ça fait très "mode"
J2EE et cela rapproche fatalement Zope de la lourdeur de J2EE.

<aol /> encore.

Mes deux centimes...

Les miens aussi.

Et je relance de trois !-)

Bruno Desthuilliers wrote:

Penser que la conception puisse être totalement découplée de
l'implémentation est AMHA un mythe.

Brève: Une dépèche de l'AFP nous signale une mystérieuse vague de suicides
parmis le corps enseignant dans le domaine du génie logiciel.