Reprise du message précédent :

Attends, il passe de PHP à Java là
 
J'pense que lui proposer un langage ressemblant un peu à Java et tournant sur la JVM c'est limite, alors lui proposer de l'Erlang, de l'OCaml ou du Haskell on va le perdre

Notons que ça remplace un subset (assez léger) de la MI, les mixins étant bien meilleurs pour remplacer la MI sans créer de graphes complexes et avoir de problèmes de MRO

1. Oui
2. Les cas d'utilisation de cette forme précise étant relativement rares en python (comparé à e.g. Java), ça n'a pas une importance primordiale.
 

Oui enfin je ne connais pas que php, non plus, hein.

Moi je lui aurait proposé D, c'est un langage hype qui risque d'avoir la cote dans certaines entreprises dans quelques années.

tu pourrais être moins clair, j'ai failli comprendre ce que tu as écris

1) ouais, mais j'ai fait 77km moi
 
2) je sais pas encore, on les voit/gratte pas tout de suite.

le HTML 3.2 et le JavaScript ça compte pas

Le monsieur te dit que ça ne remplace qu'un sous-ensemble de l'héritage multiple, mais qu'il y a bien mieux pour pas cher.

oh toi le dut fana de vb tu vas te calmer hein.

sachant que 90% de tous les points d'utilisation de ces merveilles pourraient bêtement être remplacées par une bête aggrégation ...

Les plus gros problèmes posés par l'héritage multiple (MI) sont les graphes en diamant (Une classe A définissant une méthode #foo, deux classes B et C héritant de A et overridant #foo, une classe D héritant à la fois de B et de C et ne redéfinissant pas #foo), et les problèmes d'Ordre de Résolution de Méthodes (Method Resolution Order, MRO) en résultant (genre dans le cas que j'ai donné, quel #foo doit-on exécuter sur une instance de D?)

On peut bien sûr créer des graphes d'héritage plus complexes, mais dans tous les cas là est le principal problème de la MI: la possibilité de créer des cycles, et la difficulté à résoudre la MRO au sein de ces cycles.

Mouais, c'est discutable au niveau logique (tu parles bien d'aggrégation = composition?)

Je fais du Delphi maintenant, je regarde les vbetas de haut

huhu.

j'te parle de "implements MouseListener, MouseMotionListener, Serializable, Renderer, ListSelectionListener, ListCellEditor"

C'est pas un cas d'utilisation des mixins ça

tjrs cassé l ultime topic !

blabla

Tu vois quand tu veux
(bon, j'ai rien appris mais l'intention est là)
 
Deuxième question : c'est quoi la différence entre un(e?) mixin et une classe abstraite ? c'est la même chose avec un nom différent ? ou alors c'est complètement différent ? l'article de wikipedia n'est pas super clair pour qqn comme moi

Ah ça, pour péter un topic à coup de mass-delete des messages d'un usager qui est là depuis si longtemps que sa contribution représente 300 pages, y a du monde, mais pour réparer derrière, on peut aller se faire foutre.

Je suis sur que skeye et flo850 seraient heureux d'apporter leur aide pour réparer le topic! Mais que fait joce ?!

Un mixin, c'est un héritage de comportement + un héritage d'interface, mais sans génération d'arbre d'héritage, c'est utilisé en conjonction avec la SI pour reproduire la MI sans avoir justement les problèmes d'héritages.

C'est très utilisé pour ajouter des comportements (regrouper des comportements qu'on peut ajouter aux classes par la suite), par exemple en Ruby (SI + Mixins) e.g. il existe un mixin appelé Enumerable qui fonctionne de la manière suivante

• On crée une classe (un conteneur, sinon c'est sans intérêt)
• On lui donne une méthode "each" correspondant à un contrat simple (prend un block, itère sur les éléments du conteneur, exécute le block pour chaque élément)
• On y mixe Enumerable (via `include`)
• Et paf on récupère toutes les méthodes d'Enumerable (sauf #max, #min et #sort qui demandent à ce que les objets dans le conteneur implémentent #<=> ), sans pourtant que notre conteneur n'hérite d'Enumerable (qui n'est pas une classe)

En gros, ça permet d'avoir 95% des fonctionalités de la MI sans générer les problèmes de graphes en diamant et de MRO, parce qu'il n'y a pas de concept d'héritage ou de surcharge (au sens objet du terme) via les mixins. À noter que certains langages implémentent les mixins sous forme de traits

À noter également que ça correspond à une version "affaiblie" (simplifiée) des Typeclasses qu'on peut trouver en Haskell.

 
Y'aura jamais rien de mieux que King Of Figthers
 

 
Tiens Vista...

 
Fatal Fury Real Bout 2.

Epouse moi.

*burp*

bon je constate qu'il y a toujours autant d'experts ici, donc : je pense m'acheter une télé un de ces 4 (la télé que m'a refourgué ma copine est naze : pas de rgb, pas de 60hz).
qu'est-ce que vous me conseillez, dans les 300€ grand maxi ?

bein rien, ici on aide pas les pauvres

http://www.darty.com/webapp/wcs/st [...] ic=2450941 ???

(en plus, pour pas un rond, ils peuventte livrer, et emporter la vieille)

43 kilo

300€ c'est cher pour une télé qui sert à jouer à la gamecube et regarder 1 fois par mois la télé ?

merci j'avais pas pensé à regarder darty
 

apparament les télés à tube à partir de 70cm font toutes dans les 40-50kg

c'est pour ca que je vire ma 55 cm pour un LCD de 37"

mauvaise réponse, biff  

Quelqu'un a l'intégrale (23 épisodes) de Ergo Proxy en "HD" (1280*720, les releases MKV)

tu demandes si ça n'est pas un fake???

THIS IS NOT A BOARDAAAAAA

Pas du tout, c'est juste que sur piratebay les soustitres sont en russe, merci pour ce lien

bon, au moins, si gilou nous masse delete de ce topic naissant, ça ne craint pas grand chose

 
J'ose pas encore le faire, parcequ'une sensation de cradeur profonde me pénètre quand j'y pense. Mais en C++ un #include placé à l'intérieur de la def d'une classe et qui contiendrait des méthodes ne ressemblerait pas fortement à un mixin par hasard ?
 
Après j'avoue que je vois pas trop la différence entre ça et des algos en templates, si ce n'est la gueule de l'appel qui est une méthode dans le cas de l'include et qui n'en est pas une dans l'autre cas...

   
 
Fondamentalement oui, sans aucun support syntaxique du langage, ça peut être super drôle à débugger

bon, vos retours sur feisty?
Je veux vos rapports demain sur mon bureau

Bah en même temps, tu casse rien du language, y'a pas de support syntaxique particulier à avoir...
( Si un nom est définit 2x, ce sera dit, si une méthode manque, ce sera dit, j'ai pas pensé à tout mais je vois pas trop de bug indécelable pour le moment )

( Si en fait un truc qui merde c'est qu'on peut pas include dans le fichier mixins des headers normaux, ils font la gueule quand ils sont au milieu de la def d'une classes ... )

*syntactic sugar* qu'il a dit