[API] Folco découvre l'info au taf - Page 2

Godzil -> comme tout, l'héritage multiple peut être utilisé comme un con. Ca n'en fait pas quelque chose de mauvais par essence.

Pen^2 -> Ca dépend probablement des besoins. En ce moment, je suis bien content d'utiliser ça. J'ai un objet actionneur à la base de la majorité de mes objets sur la machine. Cet objet est capable d'être contrôlé par un "mode maintenance", qui outrepasse les ordres de la machine, et remet l'élément dans son état théorique à la sortie du mode maintenance.
Ca prend 10 lignes dans cette implémentation.

Dans l'implémentation précédente, en "basic", c'était des centaines de lignes sur l'ensemble du programme, avec des risques d'erreur touchant à la sécurité en cas d'un quelconque oubli.
Dans mon cas, la factorisation du code à ce niveau, en plus d'être un gain de temps, est surtout un gain très appréciable en sécurité.

Pen^2 (./30) :
Concernant le java il ne s'agit pas exactement de compenser, mais de proposer une vision plus propre que l'héritage multiple.

Ça dépend du point de vue, hein.

Et la preuve que l'héritage multiple manque, c'est que le Java 8 a rajouté les "méthodes par défaut" (implémentations par défaut des méthodes) dans les interfaces, ce qui simule l'héritage multiple (mais est quand-même plus limité parce qu'on ne peut pas faire de l'héritage multiple de classes normales, il faut les transformer en interfaces avec méthodes par défaut). En particulier, le fameux "problème du diamant" ("diamond problem", plus correctement, mais plus rarement, traduit "problème du losange"), la principale excuse pour ne pas permettre l'héritage multiple, existe aussi avec les "méthodes par défaut".

C'est peut-être une habitude biaisée, mais l'héritage multiple ne me manque pas du tout, et d'ailleurs même l'héritage tout court ne me sert pas tant que ça.

J'ai déjà plusieurs fois utilisé l'héritage multiple en C++ et j'ai aussi déjà rencontré des cas en Java où ça m'a manqué.

Cela dit, j'ai aussi déjà eu le problème en C++ d'avoir un graphe de dérivation en losange ("diamant"), et la solution pour permettre cela proprement ("héritage virtuel") aurait nui à la performance bien plus que quelques champs membre non utilisés, donc dans ce cas, je suis repassé à un héritage simple et des champs optionnels. Ce n'était pas le "problème du diamant" classique (le conflit d'implémentations) le problème, mais la nécessité d'avoir une seule copie des champs de la classe de base.

Ah tiens, je me suis fait la même réflexion, j'aurais aimé avoir une implémentation par défaut pour les méthodes, malheureusement ce n'est pas possible...

Kevin > non, les implémentations par défaut des interfaces ont été introduites pour permettre de les faire évoluer, c'est dit explicitement -- ajout de méthodes pour une interface utilisée par des classes dont on n'a pas le source.

Mais cette fonctionnalité est utilisée en pratique pour bien plus que ça. Cela dit, il reste quand-même la grosse limitation que les interfaces ne peuvent pas avoir de variables membre et donc on ne peut pas y mettre des méthodes qui gardent un état sans bidouilles affreuses (genre une classe MyInterfaceData ou MyInterfaceImpl avec un static HashMap<MyInterface, MyInterfaceData> dataMap;).

Ça prouve donc juste que des gens (?) pas très avisés détournent une fonctionnalité pour faire une chose qui est généralement admise comme étant problématique de manière ultra gore, pas que ça a été ajouté dans la spec pour palier un quelconque manque de cette nature

Pour revenir à l'héritage multiple, on peut avoir besoin d'avoir un objet cheval qui hérite de mammifère et de véhicule, hein

?

Ce soir, je viens de lire et écrire pour la première fois des messages SDO avec succès !!!
Sur un moteur brushless, j'ai donc un contrôle 100 fois plus étendu qu'avant, avec accès et modifications des valeurs par défaut de vitesses, des rampes d'accélérations et de décélérations, contrôle de tout un tas de status, et même certains contrôles de vitesses, qui nous ouvrent la porte à un mode de coulage de paraffine, voulu par le patron, mais infaisable jusqu'alors

Folco (./39) :
coulage de paraffine

C'est pourri, les bougies à paraffine, c'est du carburant fossile, ça pue, ça coule, c'est carcinogène, …

Avoir des définitions de membres sur les interfaces casse l'encapsulation puisque c'est littéralement dire qu'on peut accéder à des structures directement, sans contrôlés par des mutateurs.

En C# on a les propriétés mais ce n'est que du synraxic sugar pour des getter/setter

Warpten (./43) :
Avoir des définitions de membres sur les interfaces casse l'encapsulation puisque c'est littéralement dire qu'on peut accéder à des structures directement, sans contrôlés par des mutateurs.

L'idée serait d'avoir des membres privés, utilisables dans les méthodes par défaut.

Et quel est l'intérêt d'imposer l'existence de membres privés ? Le principe d'une interface c'est de définir un contrat, pas une implémentation

À part de l'introspection (quelque chose de très borderline en soi)

Lis le contexte. Le Java permet de définir des implémentations par défaut pour les méthodes de l'interface (pour permettre notamment l'évolutivité des interfaces), mais la grande limitation est qu'on ne peut pas y garder un état. C'est dans ce contexte-là qu'on parle de membres dans une interface (interdits par le Java à l'heure actuelle).

Évidemment que ça n'a aucun sens dans une interface pure (surtout un membre privé, qui ne serait accessible nulle part).

À ce compte là, les interfaces deviennent des classes abstraites, avec de l'héritage multiple dans la sauce...

Et c'est pas idiot comme mix.
Dans mon cas, je n'ai droit ni à l'héritage multiple ni aux membres dans les interfaces, et ça m'emmerde.
Concrètement, je voudrais une interface pour initialiser des valeurs par défaut dans différents modules, et un simple booléen pour retenir si ces valeurs ont été initialisées.
C'est pas possible avec une interface, ni en une étape de dérivation.

La seule solution que je vois, c'est une classe bidon supplémentaire pour ajouter un objet contenant une méthode et un booléen, avant de dériver vers la classe qui m'intéresse réellement.

C'est une lourdeur inutile...

---

hihihi, en fouillant dans l'IDE, que je découvre, je me rends compte qu'il y a en fait des propriétés d'interface !! \o/
Fichier joint :

J'en va tester ça de suite

(ouah, l'IDE en français, Monsieur a des goût de luxe )

C'est automatique. Je vais de ce pas réparer cette hérésie.
Surtout qu'il y a des items chelous dans les menus :
"compiler" -> ok, ça compile
"compiler tout" -> ah en fait, c'est un rebuild all

Tiens, je ne m'attendais vraiment pas à te voir écrire un jour que le français était une hérésie par rapport à l'anglais

mouarf en effet
Mais bon, l'info est un domaine exceptionnel

C'est surtout ton emploi hérétique du mot "hérésie" (quand-même un "crime" grave dans le "droit" chrétien) qui surprend.

Bon, vu que le modèle polling-based c'est quand même bien de la merde, je me tâte pour écrire un joli wrapper de programmes, qui leur fournirait une event loop.
J'en bave d'avance, malheureusement j'ai absolument pas le temps de me lancer dedans