Philip Marlowe a écrit 1173 commentaires

Oulà ! j'avais mal regardé. Ton invariant est complètement extravagant. Déjà le fait de ne pas être inversible pour une matrice déclenche une exception. Tu n'aimes pas la singularité ! Tu codes ensuite if m.inversion_reussie then que je traduis par : s'il ne s'est pas produit d'exception... De toutes façon ce code ne sera jamais exécuté car la simple crétion d'une matrice, même inversible, va engendrer une exception.

Ensuite il y a un autre critère de qualité qui s'appelle le masquage d'information. Les clients ne doivent pas avoir accès à l'implémentation de la classe.

Tu es passé d'une fonction à une procédure... Sinon ton point de vue est pertinent. Pour utiliser mon code, c'est un tout petit peu plus simple.

x:= m.inverse
if x /= Void then traitement normal
else traitement de l'erreur
end

il faudrait alors mettre à jour ce drapeau dès que l'on modifie une valeur de la matrice
Là je ne suis pas d'accord. C'est un des principes de la conception à objets que de ne pas modifier ceux-ci de manière intempestive. Si tu as besoin de modifier des coefficients de la matrice, il faut en créer une autre !

On ne m'a pas rattrappé par les bretelles... Il vaut mieux éviter de tenter d'inverser plusieurs fois une matrice qui ne peut pas l'être, d'accord, mais calculer plusieurs fois le résultat de l'inversion quand cela a déjà été fait une fois ne vaut guère mieux.

On peut donc ajouter un attribut non visible, par exemple resultat_inversion: MATRICE.

on peut modifier le corps de la routine par
require [...]
do
if already_tried then
Result := resultat_inversion -- si ça a foiré précédemment resultat_inversion = Void
else
Result := un_calcul_compliqué
resultat_inversion := Result
already_tried := True
ensure [...]
rescue[...]
end

La clause d'exception permet d'effectuer un_calcul_compliqué sans filet (un des risques est de tenter de faire une division par zéro). Il va de soi qu'il est possible de faire autrement.

On peut même améliorer les choses en déclarant already_tried comme attribut plutôt que comme variable interne à la routine et éviter ainsi de tenter d'inverser plusieurs fois une matrice qui ne peut pas l'être.

A remplacer : dans le sens de la routine par au sens de la routine.

Je suis d'accord avec tes objections, cependant même en Eiffel on est parfois astreints à des impératifs d'efficacité. Ton code présente bien l'utilisation des assertions mais avec un mauvais exemple.

D'abord la vérification de la non singularité de la matrice par le calcul de son déterminant, ou par la méthode de Gauss implique un volume de calcul du même ordre que l'inversion proprement dite.

La postcondition souffre de quelques lacunes aussi. Déjà avec un x: DOUBLE différent de zéro, x * 1/x = 1 n'est pas toujours vrai. Il va donc plutôt falloir trouver un autre critère comme, par exemple, calculer la norme de la différence entre le produit de la matrice par son inverse et l'identité, et vérifier qu'elle est inférieure à une certaine tolérance.

je propose donc le code suivant comme exemple amélioré (à ne pas considérer comme étant taillé dans le bronze) :

inverse: MATRICE is

require

is_square -- on ne traite pas les pseudo inverses

local

already_tried: BOOLEAN

do

if already_tried then

-- Result := Void ceci est un commentaire

else


--code de tentative d'inversion de la matrice

end

ensure

Current = Void or else (Current * Result).distance (identity) < epsilon -- epsilon attribut de la classe

rescue

already_tried := True

retry


end

En procédant de cette manière on va obtenir une approximation de l'inverse de la matrice si la matrice n'est pas singulière et que le code le permet et un objet vide dans les autres cas. L'avantage c'est que si la matrice n'est pas inversible dans le sens de la routine (ce qui ne veut pas dire qu'elle ne l'est pas mathématiquement), l'objet retourné sera vide, ce qui décharge le client de lourdes vérifications.

Un exemple est donné, tourné autrement, dans Conception et programmation orientées objet de Bertrand Meyer, pages 771 et 772.

Pendant que j'y suis. Ce n'est pas une perte de temps d'essayer la version gratuite de EiffelStudio, actuellement en version 5.5. Il y a un formulaire à remplir pour y accéder, mais l'accès direct est ici : ftp://ftp.eiffel.com/pub/downloads/(...) et on y trouve les exécutables pour Linux, Solaris et Windows. Je sais, c'est propriétaire, mais voir à quoi ça ressemble et comment ça marche ne rendra personne idiot. Ca peut même donner des idées.

ISE was privileged to be one of the outside language providers selected, more than a year before the first official announcement of .NET [...]
Tu as raison. On leur a demandé de collaborer pour fournir un langage externe ayant .NET comme cible.

Oups ! C'est à Philippe Piette ci-dessous que je voulais répondre.

http://www.google.fr/search?q=cache:PFejj65lq4MJ:archive.eiffel.com(...)
C'est en cache de Google, l'original n'est plus disponible, peut-être à cause de son caractère polémique, en particulier à l'encontre d'un certain Bob Metcalfe.

Ce qui est amusant c'est que la routine d'inversion de matrice montrée en exemple n'est justement pas le meilleur exemple pour l'utilisation des assertions, surtout de la précondition. Vérifier qu'une matrice est inversible prend autant de temps que de l'inverser, ce qui fait qu'en l'occurence on choisira plutôt de traiter le problème en utilisant la gestion des exceptions avec une clause rescue.

Les pré et postconditions sont abandonnées sur les exécutables finaux, ce qui fait qu'un programme mis au point avec la précondition indiquée va mettre des contraintes énormes sur les clients de la routine d'inversion de matrice en les obligeant à prendre à leur charge la vérification préalable de l'inversibilité de la matrice passée en argument, sauf dans le cas qui me semble douteux où une preuve de l'inversibilité des matrices passées en argument serait préalablement apportée.

C'est un peu du pinaillage que je fais là mais j'aime autant prendre les devants plutôt que de voir quelqu'un affirmer "Eiffel ça vaut rien d'ailleurs ça se voit bien sur l'exemple".

Ce n'est pas si simple. Au niveau du langage, l'histoire de l'insert est la seule qui me vient en tête. Par contre c'est au niveau des bibliothèques de base que se posent les problèmes.

Pour apprendre les bases du langage toutes les implémentations se valent. Pour la partie apprentissage des bibliothèques le problème se pose. Pour adapter un projet écrit avec un compilateur sur un autre, ça se complique sérieusement.

Les autres acteurs du monde Eiffel se plaignent du manque de respect des standards du genre par l'équipe de SmartEiffel. Par exemple l'héritage non conforme est déclaré avec le nouveau mot-clef insert. Les récentes versions d'EiffelStudio utilisent le mot-clef déjà existant expanded. SmartEiffel pose beaucoup de problèmes à GoboSoft, fondé par Eric Bezault http://www.gobosoft.com/(...) qui propose des bibliothèques compatibles avec le plus de compilateurs Eiffel possible (il n'y en a pas tant : de mémoire, SmartEiffel, EiffelStudio de Eiffel Software http://www.eiffel.com/(...) et Visual Eiffel d'Object Tools http://www.object-tools.com/(...) Halstenbach semble ne plus exister).

Pour ce qui est justement de la définition des standards, qui au départ devait être assurée par NICE (Nonprofit International Consortium For Eiffel http://www.eiffel-nice.org/(...) , elle semble maintenant dévolue à l'ECMA. I ya eu quelques discussions un peu chaudes à ce sujet sur les mailing lists Eiffel.

J'utilise Eiffel au travail (environnement propriétaire EiffelStudio sous Windows, il en existe aussi une version GTK2 sous Linux), et cela a beaucoup influencé ma manière de concevoir (cela n'est cependant pas ma spécialité). J'aurais du mal à me passer de la Programmation par Contrats et de l'héritage multiple, ainsi que du confort de l'environnement de programmation proposé par EiffelStudio. A ce propos, y a-t-il des gens qui le connaissent et qui, pratiquant d'autres EDI avec d'autres langages, seraient à même de comparer ? Cela m'intéresserait.

Ce qui est complètement invraisemblable, c'est que Microsoft produise quoi que ce soit d'important sous licence GPL. Ils n'ont jamais perdu une occasion de la dénigrer, et pour cause, elle contrevient totalement à leurs intérêts.

Pardonne-moi d'avoir blasphémé.

Oui, MS abandonnera peut-être même alors la plate-forme .NET pour développer un clone libre de Java en GPL. Qui parlait de marmotte ?

GPL semble être considéré comme un gros mot chez MS. Puisque tu y travailles, pourrais-tu répondre à une question qui me taraude à ce sujet ? Quand quelqu'un parle de GPL chez MS, doit-il après se laver la bouche au savon ?

Peut-être me suis-je mal exprimé ? Ou aurais-tu mal compris ? Sun a moins besoin de la communauté du libre pour coder OOo que pour l'adopter et le répandre. Parce que des boîtes qui faisaient des suites bureautiques sur un mode propriétaires, il y en a eu. Où en sont-elles ?

En tout cas je n'ai jamais voulu dire le contraire...

Où en serait Star Office, racheté par Sun, si cette suite était restée purement propriétaire, et s'était posée sur cette base comme concurrente de Microsoft Office ? J'en ris...

Soyons positifs : le fait que cet accord ait été porté à la connaissance du public a le mérite de clarifier les choses...

Autre chose : ce qui pue le plus dans cet accord, c'est le fait qu'il ait été gardé secret. Les manoeuvres de coulisses, c'est pas beau !

Tu expliques les choses comme si Star Office était un projet natif de Sun. En fait Sun a racheté Star Division, boîte d'un génial allemand qui avait créé Star Office. C'est un point de détail, mais qui vaut d'être rappelé. Il ne faut en particulier pas trop invoquer les capacités crétrices de Sun à ce sujet.

Les majuscules indiquent l'unicité de ce qui est désigné par le groupe nominal. René (même s'il n'est pas seul à s'appeler ainsi), la Liberté, le Parti Socialiste, Dieu...

Ici c'est la bonne place pour cette enfilade, qui a trait à ce qu'une autre enfilade de cette nouvelle ait disparu vu que, en insistant lourdement, c'est ici qu'elle était. Il faut porter l'huile là où est le feu...

Je suis bien d'accord avec ce que tu dis par ailleurs, mais ça n'explique pas pourquoi mes votes positifs pour les commentaires de Yeupou (Gnap Gnap), que j'estime pertinents dans ce cadre, n'ont pas été pris en compte. A titre d'information, je n'ai cherché à moinsser personne dans cette enfilade, juste à plusser pour faire apparaître des commentaires qui me semblent inopportunément occultés.

Je réitère ma remarque sur la façon de s'exprimer des visiteurs...

Toi, tu dis des bassesses sans dire de gros mots.

Quelques minutes et déjà à -1. "Cachez ces commentaires que je ne saurais voir." C'est donc bien une censure et la qualification initiale de son caractère stalinien est à peine exagérée, d'autant que les éléments que vous cachez ne présentent aucun caractère répréhensible du point de vue légal. C'est un paravent derrière lequel vous ne pourrez donc vous abriter. Ce sont des méthodes d'arrière-cuisine.