> > 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 Tsp-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tsp-devel