Re: [Tsp-devel] [PATCH] Correction temporaire pour xmlrpc

[dufy]

STOP au TROLL sur les langages de script, il s'est trompé de thread de
discussion..... Il doit aller retourner voir sa mère ici
http://lists.gnu.org/archive/html/tsp-devel/2006-03/msg00061.html

Je dis aussi bravo à Fred & Stéphane pour cette démonstration de puissance open source mondiale !!!
On va enfin  pouvoir faire des clients TSP qui brillent sous
Windows, voir même les integrer dans des butineurs d'internets comme IE
et ses copains !!!!
Snif, C'est beau comme une promesse électorale tenue !

Y++

PS : A force d'intégrer des milliers de bindings scripts vers TSP, on a
avoir l'arborescence principale de TSP commme un trou du cul en
choux-fleur (_expression_ typiquement canadienne, que je vous offre
gratuitement en licence RAFVFPL (Rien à Foutre de ce que Vous en Faites
Public Licence)!
Ne pourrions nous pas créer un niveau supplémentaire d'arborescence du
genre bindtsp ou dedans on retrouverait perl, tsp, python, et tous les
autres merveilleux langages de scripts qui sont nos amis pour la vie ?

Le 07/04/06, Erk <address@hidden> a écrit :

> > Et puis, pour l'anecdote, voici le 1er programme complet de 3 lignes en
> > Ruby 1.8 a avoir
> > pu parler au canal de commande XMLRPC d'un provider RPC...
> >
> > require 'xmlrpc/client'
> > server = XMLRPC::Client.new("localhost", "/RPC2", 8000)
> > server.call("tsp.tsp_provider_information").each { |key,value| puts
> > "#{key} is #{value}"}
> Quel langage de script merveilleux! Comment se fait-il que certains utilisent
> un animal à sang froid pour programmer?

Bon là évidemment je reconnais c'est succinct :)))
Mais un jour moi aussi je vous balancerais un script de sang froid :)

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

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?

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

Que faire de
a.method(b)?
ou même
a+b
ou encore
a+b+c+d
voir
a.method(b,c,d);
c'est pas mieux
somme(a,b,c,d)?

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

ouf  il vient de loin celui là :)))

Sinon sincèrement bravo pour le TSP+XMLRPC+Ruby.
Stéph' si tu es intéressé on peut sans pb créer un module
de haut niveau

rubytsp

ou tout autre nom approprié à ce diamant :))
--
Erk


_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel