Re: RE : [Tsp-devel] Troll sur languages de script

[Erk]

Le 08/04/06, Stephane Galles<address@hidden> a écrit :
> >On remarquera au passage que la methode "a.__len__"
> >est en fait elle-même un objet, un objet methode.
> >donc je pourrais très bien faire:
> >
> >>>>b=a.__len__
> >>>>b()
> >>>>
> >7
> >
> >Donc c'est qui l'objet a ou b quand les méthodes de a sont des objets?
> >
> >
> Sur ce dernier point c'est très bien mais je ne pense pas que cela entre
> en contradiction avec ce que
> je disais.  Ou bien je n'ai pas compris ce que tu voulais dire.

Ce que je voulais illustrer (mais très mal je te l'accorde)
c'est que lorsque la méthode elle-même
est un objet alors on se retrouve avec un objet "appelable"
dont le premier paramètre n'est même pas visible.

on ne fait myobj.b()
mais juste
b()

c'est comme si l'objet destinataire du message avait disparu.

> >D'ailleurs prétendre que "C'est plus objet" de faire  a.method()
> >que method(a) me laisse perplexe
> >car c'est prétendre que le seul objet destinataire
> >de l'appel de la méthode est "a".
> >
> Hein ?! Cette dernière affirmation heurte un peu mon intuition.

Je suis d'accord avec toi avec un seul paramètre ma remarques est idiote.

> >Que faire de
> >a.method(b)?
> >
> >
> A est toujours le seul et unique destinataire du message method.
> B est un paramètre, pas un destinataire.

Sauf si "method" est un operateur....mais tu en parle après
Sauf également quand il se trouve que:

a.method(b) fasse en fasse en fait
b.visit(this) (ou this == a)

et tu reconnaitras le pattern du visiteur qui sert
justement à implémenter un double dispatch
quand on ne dispose que du single dispatch objet.

est-ce que ça aurait été moins objet de faire
visit(a,b)
surement.
Est-ce que c'est plus simple à implémenter sous
forme fonctionnelle pure qu'avec un visiteur
personnellement je pense que oui.


>
> La différence est majeure me semble - il:
> lorsque A.method(B) est executé, A a la responsabilité de l'execution de
> la méthode.
> Cela me communique que l'unité de traitement pour la méthode est dans A,
> pas dans B.
> Ce me communique également que lors du traitement A.method(B) les
> interfaces publiques
> et privées de A vont être impliquées, mais seule l'interface publique de
> B peut être impliquée.
> Enfin cela me communique que le message 'method' a surement plus de lien
> avec les
> données de a que celle de b (en partant du principe que l'objet A est un
> bon objet :  à savoir
> on a regroupé le traitement et les données sur lesquelles agissent les
> traitements :
> c.f : GRASP Pattern "Information Expert" :
> http://people.msoe.edu/~blessing/cs489/cs489-13ch18.pdf

je vais lire ça tranquillement.
Mais mon idée était que pour les méthodes qui prennent plusieurs
paramètres je trouve que ce n'est pas toujours évident
de trouver qui est le "meilleur" destinataire.

Ensuite il y a des catégories d'algorithmes qui s'implémentent
naturellement avec des fonctions pures.
Max, Min, Find (en gros des opérations sur des collections).

On peut évidemment créer des objets collections qui contiennent
ces méthodes mais c'est sincèrement relativement artificiel.
Je préfère un algo fontionnel qui prend en paramètres quelques
itérateurs, comme celà est fait dans la STL.
http://www.sgi.com/tech/stl/


> >ou même
> >a+b
> >ou encore
> >a+b+c+d
> >
> >
> Ce sont des cas particulier : celui où les objets sont du même
> type, et que l'opérateur est commutatif.

objets du même type je ne suis pas d'accord.
je peux vouloir ajouter un vecteur à un point et
cela me donnera un point.
un vecteur à un vecteur et j'aurais un vecteur.
Donc je dois implémenter des 2 operations d'additions
dans vecteur et dans point?
Que se passera-t-il quand j'aurais une nouvelle classe
(pas prévue) dont les objets sont susceptibles de s'additionner
avec mes anciens Vecteur et Point?
je pourrais faire:
NewVecteur+Point
et
NewVecteur+Vecteur
mais probablement pas
Vecteur+NewVecteur (sans modifier l'ancienne classe)

En C++ tu pourrais définir une fonction template
(non attachée à une classe) et faire de la spécialisation partielle.
(dans le cas des types diffrents)
ou utiliser des 'traits'.
http://www.cantrip.org/traits.html


> On ne peux pas généraliser avec ça.

Je suis d'accord c'est un peu spécial, mais ça arrive
quand le côté "fonctionnel" de la méthode profiterait
à ne pas être attaché à une classe/objet particulier.

> >a.method(b,c,d);
> >c'est pas mieux
> >somme(a,b,c,d)?
> >
> >
> Encore un fois, somme(a,b,c,d) est un cas particulier où a, b, c et d
> ont vraissemblablement le même poids vis à vis du traitement.

Oui l'important ici c'est la somme pas a,b,c,b
et ça se généralise à d'autre opérations du genre accumulation.
http://www.sgi.com/tech/stl/accumulate.html

> >Les langages OO "simples" font du single dispatch implicite
> >(on passe implicitement en premier argument d'une méthode
> > une référence/pointeur de l'objet SUR LEQUEL la méthode est appelé).
> >
> Oui, on est d'accord, mais ce n'est pas pour rien (généralement) que c'est
> sur cette objet que la méthode est appelée. Et c'est important que la
> notation le distingue des autres objets. Je trouve perturbant que Python 
> utilise à
> la fois les notations A.foo() et foo(A) pour dire la même chose.

Je suis d'accord pour len celà peut paraitre inutile et troublant
mais néanmoins ça me parait utile que même des langages 100% objets
permettent la définition d'objet purement fonctionnel, donc des fonctions.

>
> >alors qu'on pourrait faire du "multiple dispatch"
> >pour aboutir à une multiméthode
> >http://c2.com/cgi/wiki?GenericFunction
> >ce qui est bien sûr faisable en quelques lignes écrite de sang froid:
> >http://www.artima.com/weblogs/viewpost.jsp?thread=101605
> >
> >
> Hum... j'ai comme l'impression qu'on perd alors la notion
> d'encapsulation et
> de cohésion qui fait l'intéret de l'objet : on a séparé données et
> traitement.
> (style 'friend' du C++). Mais bon, j'imagine que cela doit avoir
> des cas d'utilisation

Les cas que je connais sont surtout dans le domaine numériques
ou les objets sont des points, vecteurs, matrices  etc... et les méthodes
des opérations sur ces objets.
Le single dispatch devient réellement pénible quand tu as une hiérarchie
de matrice et que tu veux avoir une méthode polymorphe qui fait

A = B*C+D


C'est sincèrement pénible ou au minimum TRES inéfficace quand
tu veux optimiser les objets temporaires ou éviter les calculs inutile.

Un exemple simple, le produit scalaire de 2 vecteurs V1 et V2.
V1 et V2 font la même taille sauf que V2 est "creux" c'est à dire que
c'est une sous-classe de Vecteur qui est optimisé parce qu'on sait
qu'il contient une majorité d'éléments nuls.

si je fais
1) a= V1.scalaire(V2);
ou
2) a=V2.scalaire(V1);

dans 1) je vais faire une boucle sur 1000 éléments alors
que 2) ne fera qu'une boucle sur les éléments non nul
de V2.

Une bonne fonction:

a= prod_scalaire(V1,V2);

s'arrangera pour TOUJOURS exécuter la version la moins chère.


>
>
> En résumé, je suis d'accord que c'est tres bien que dans l'expression
> len(s), ce soit l'objet s qui soit appelés,
> (puisque c'est de sa responsabilité de calculer sa propre taille) mais
> je ne vois tout simplement
> pas l'interet de la masquer et de ne pas utiliser la notation objet qui
> communique vraiment cette information.

Je suis d'accord pour len je n'y vois pas d'intérêt non plus.

>
> Je connais mal Python, mais j'ai effectivement l'impression que ses
> dernières évolutions se dirige de plus
> en plus vers l'object, ce qui est très bien. Néanmoins, on sent que les
> fondements initiaux
> sont quand même procéduraux (voir cette liste de fonctions deprecated
> http://docs.python.org/lib/node111.html)

Ben oui je suis aussi d'accord.

>
> Pour l'instant je regarde du coté de Ruby parceque vu de ma petite
> fenêtre object j'ai
> l'impression que les pièces du puzzle s'imbriquent mieux. C'est peut
> être juste une impression, mais
> voyon cela comme un effet placebo...si cela me convient ainsi ;) Après
> tout je peux toujours
> changer d'avis après l'avoir vraiment pratiqué !

Pareil pour moi pour Python je pourrais changer
après avoir vraiment pratiqué.


Mon objectif global n'était d'ailleur pas tant de justifier
les "erreurs" d'API foncitonnelle de Python mais plutot
de remarquer que le "tout objet" n'est parfois pas la meilleure
solution. Donc un langage objet qui permet de faire un peu
de fonctonnel/procédural me parait bien sympathique.

J'ai écris ce mail en 3 fois donc je m'excuse d'avance
des ruptures de sens :))

--
Erk