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

[Stephane Galles]

Le Troll a rejoint sa maman à la caisse numéro 6 du magasin.

On peu continuer.

Erk wrote:

> Sans vouloir relancer le troll suite à une remarque de Julien
> il s'avère qu'en Python
>
> len(a)   génère en fait un appel la méthode spéciale  a.__len__
>
> Un petit exemple vaut mieux qu'un grand discours.
>
>  
>
> > > > a="HKKJHKj"
> > > > a.__len__
> > > >        
> <method-wrapper object at 0xb7b5672c>
>  
>
> > > > a.__len__()
> > > >        
> 7
>  
>
> > > > len(a)
> > > >        
> 7
>  
>
>
>  
OK, je ne savais pas que l'appel se faisait sur l'objet String lui même. 
Très bien.
J'étais choqué par le fait qu'il semblait qu'on avait retiré un partie de
la responsabilité de l'objet String. Donc tout va bien... Ou presque, 
car j'ai encore un
problème avec cette notation. Mais on y arrive un peu plus loin...

> 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.

> 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.

Moi je dis le contraire : quand on écrit A.method(), A est le seul
destinataire du message method. C'est même la définition d'une transmission
d'une message à un objet.

> 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.

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
)

> 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. On ne peux pas généraliser
avec ça.

> voir
> 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.

> 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.

> 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


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 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)

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é !

Steph.


Stephane Galles wrote:

> address@hidden wrote:
>
> > Mouaih je connaissais Linda
> > http://en.wikipedia.org/wiki/Linda_%28coordination_language%29
> >
> > c'est un bel outils pour les expérimentations théoriques
> > en programmation parallèle et distribuée.
> > [...] 
>
>
> Bon, je te dirais que je parlais un peu de ça sans raison précise :)
> Moi je ne connaissais pas avant de la voir dans Ruby...
> c'est le fait qu'un truc comme cela soit livré en natif avec Ruby
> qui m'a fait alluciner. Ce n'est pas courant... pour le moins...
>
> Sinon, plus sérieusement :
>
> Concernant le message de dufy sur LUA : Cela a l'air très bien 
> effectivement.
> Pour l'instant, cela me rappelle beaucoup la syntaxe de Ruby. Les bloc 
> if/end
> et l'assignement multiple en particulier.
>
> Pour être concret, je voulais juste vous envoyer vers le petit bout de 
> code Ruby
> qui m'a fait dire : "Il faut que j'apprenne ce language !".
> C'est un exemple en 3 pages de client/serveur de discussion texte qui 
> broadcast à tout ses client ce que
> qu'un des client écrit. Y'a un peu de tout là dedans, du thread, du 
> mutex, pattern observer.
> (tout ce qu'on peut retrouver dans un client TSP  ;) )
> C'est tellement lisible et compacte qu'on dirait du pseudo-code.
> c.f. pages 34,35,36 de ce PDF (paragraphe "A chat system - OO Version")
> http://www.ruby-doc.org/docs/Immersive%20Ruby%20programming%20course/RubyCourse_1.0-1.pdf 
>
>
>
>
>
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel