Philip Marlowe a écrit 1187 commentaires

Merci pour tes explications qui sont cette fois limpides.

Je rappelle le titre du thread : Et le Troll, il arrive quand ?

Et la concurrence, elle arrive quand ?

Merci pour les liens.

Ceci dit le titre du thread est : Et le Troll, il arrive quand ?. Comme Nicolas Raynaud semble vouloir un troll, je fournis un sujet possible.

Ca fait deux ans que j'utilise Eiffel au travail, et le problème de la covariance / contravariance ne s'est jamais posé pour moi. Ce sont, à ma connaissance, les fondateurs de Sather, langage issu de Eiffel, qui ont prétendu que l'utilisation de la contravariance renforçait la sécurité du code. L'exemple que je fournis plus haut montre que cela pose problème avec un cas trivial : si l'argument de la comparaison avec l'objet courant ne peut pas varier dans le même sens que celui-ci, la comparaison (est-ce que cet objet est égal à l'objet courant ?) ne fonctionne plus avec les héritiers. Il va de soi que la bonne manière de déclarer l'argument de la fonction est :
is_equal (other: like Current): BOOLEAN is require préconditions do ensure postconditions end
Ceci évitant d'avoir à redéfinir la comparaison pour les héritiers.

Pour mémoire, le sujet de la news est SmartEiffel, donc Eiffel. Tu parles de problèmes qui ne sont pas communs à tous les langages objet supportant l'héritage multiple, mais seulement à C++ qui permet de coder en orienté objet. L'arithmétique des pointeurs n'a carrément pas de sens en Eiffel. Les cast sont typiquement C++.

Bref condamner l'héritage multiple en prenant C++ pour exemple ne permet pas une démonstration rigoureuse.

Sous Linux : Glade.

La dernière version en français de OOSC : http://www.eyrolles.com/php.informatique/Ouvrages/9782212091113.php(...)

Par rapport à la première édition française de l'ouvrage, qui était chez Interéditions, le nombre de pages a quasiment triplé !

Tant qu'à troller, autant le faire sur le thème covariance / invariance / contravariance. Peut-être que des épigones de Sather vont se manifester.

Pour ma part, ce débat me passe souvent largement au-dessus de la tête, sauf pour au moins un aspect : l'affirmation la contravariance résoud tous les problèmes. Il suffit de montrer par un exemple que ce n'est pas vrai.

Prenons une classe FOO quelconque avec une fonction de type booléen is_equal (other: FOO). Y a-t-il un chantre de la contravariance qui peut m'expliquer comment on se débrouille avec les héritiers de cette classe pour garder à cette fonction le même sens ?

Sur ce (peut-être) bon troll.

D'autre part, je constate avec amertume que la suffisance, ici, est toujours de mise.

Ce n'est pas de la suffisance, c'est justement de l'amertume. Si je t'ai froissé, je m'en excuse sincèrement. Où as-tu appris l'économie et l'instruction civique ? Chez Barnum and Bailey ? Ce n'est pas la meilleure école, même s'ils font par ailleurs des choses intéressantes.

[Pour plus d'infos, lire le que sais-je 'Economie sociale']

Merci. S'il y a dedans une définition de la progressivité de l'impôt, ce ne serait pas un luxe que tu la lises.

Moi, ce qui me gêne le plus en ce moment, c'est la fermeture du pont de la Menoge, entre Annemasse et Bonneville. Je ne le prenais pas, mais ceux qui le faisaient empruntent ma route. Par contre, point de vue odeurs de poubelles, rien à signaler.

Comment ? C'est hors sujet ?

Dans la série "l'impôt juste", je te mets sur la voie : il y a des impôts à taux progressif et d'autres qui ne le sont pas. A ton avis, dans quelle catégorie se range la TVA ?

Ici (Espagne), ils ne font pas grève car ce n'est tout simplement pas dans les mentalités!

Non, ils font directement la révolution ! D'accord, ça fait un moment que ça n'est pas arrivé...

Meyer étant loin d'être un con, j'ai l'impression d'avoir raté quelquechose, quelqu'un voit où est mon erreur ?

Tu ne dois pas être non plus un con. Je viens de tester ton exemple sous linux avec ISE EiffelStudio 5.2.

En effet, en faisant l'affectation s := a que tu décris, on peut placer des éléments dans la pile en utilisant la routine de la classe ARRAY [G], put (item: G, i: INTEGER) appliquée sur l'objet s. La même chose est impossible en passant par l'objet a,qui est en mémoire la même référence pointant donc sur le même objet.

Donc on manipule s comme un ARRAY [G] et a comme un ARRAYED_STACK [G], de la sorte un a.remove est valide et un s.remove provoque une erreur de compilation. Plus : s est un ARRAY et a est un ARRAYED_STACK dont les données sont malencontreusement accessibles par d'autres moyens que ceux prévus par sa classe.

La méthode suggérée par Jean-Yves Burlett de déclarer STACK comme le type statique de a élimine le problème, mais il faut s'en être aperçu.

Fait chier, je suis de soutenance ce jour !

Où ça, à Annecy ?

Ca fait un petit moment qu'il n'y a plus de tutoriels GTK dans LM...
C'est dommage, le désopilant dessin qui souvent l'illustrait me manque. Bon, ce mois-ci, on a une compensation avec celui qui flanque l'article sur la modification du noyau Linux pour prendre en charge un clavier Logitech. Ca change des dessins même pas drôles de Reiser !

Merci pour la traduction. C'est une contribution significative qui nous change des pleureuses du genre ouin, je peux pas voter !!!

Le langage dans lequel la notion d'agent est implémentée est Eiffel. La définition est l'application des concepts objet à la notion d'opération. Comme je n'en sais pas beaucoup plus, que je ne l'ai jamais utilisée, et que la possibilité de créer des mécanismes transversaux me semblait proche de la notion d'aspect que tu exposes, je venais me renseigner.

Euh, j'ai rien compris non plus. Est-ce que le concept d'agent que l'on trouve dans certains langages est proche ?

J'étais peut-être mal luné, mais il me semble que le post de départ, s'il manie l'humour, c'est celui du genre quinze tonnes par essieu. Ceci dit, tout le monde peut se tromper.

Le second degré aussi arrive à sentir mauvais... t'es pas doué pour ça.

On dirait que tu as plein de bonnes idées pour faire avancer le logiciel libre, et la liberté en général.

Eh, Pierre Jarillon, qui postes une réponse au-dessus, tu nous avais plutôt habitué à des réflexions intelligentes. C'est ton quart d'heure de connerie ?

Termine plutôt par "point barre de chez point barre", ça fait encore plus classe.

Faut mettre plein de smileys quand tu fais de l'humour. Les smileys, c'est comme les rires enregistés dans les séries supposées comiques. Si on ne nous dit pas où il faut rire, comment savoir que c'est drôle ?

Moi, je vois ça sous cet angle : chaque euro de différence entre une solution libre et une solution fournie par Microsoft est un euro de moins à utiliser de manière plus pertinente pour soigner les gens (vous, moi...).

Voilà, je suis bref.

Position de Debian par rapport aux allégations de SCO. Il a été demandé deux fois la semaine dernière si les allégations de SCO, anciennement Caldera, une entreprise orientée GNU/Linux, affectaient le projet Debian. Ray Dassen a expliqué que le problème jusqu'à maintenant consiste en allégations et rumeurs d'une société qui est loin sur le chemin de l'obsolescence. Ils ont encore à fournir quelque chose qui pourrait être considéré de loin comme une évidence, alors qu'il y a des indications concrètes que SCO elle-même a violé la GPL en incluant du code de système de fichiers sous GPL du noyau Linux dans son noyau propriétaire (Unixware ?). Une analyse détaillée a été diffusée plus tôt par l'Open Source Initiative

Extrait des Debian Weekly News du 20 mai. ( http://www.debian.org/News/weekly/2003/20/(...) )

Remplacez évidence par preuve (erreur de traduction).