Hello, J'avais écrit un article à propos de certains trucs fun qu'on peut faire avec les Procs, dans le cas où cela t'intéresse : http://jhchabran.com/blog/2012/12/09/fun-with-to-proc-and-compositions/
Par contre, je n'affilierais pas les Procs avec la méta-programmation. C'est juste un argument comme un autre qui est passé en paramètre. Il se trouve juste que cet argument est une fonction (anonyme et closure en l'occurence). Cela dit, ce que je pense, sous-entends Sylvain, est qu'on s'en sert par contre pas mal dés que l'on mets les pieds dans la meta prog, genre #define_method qui lui prends donc une Proc pour définir le comportement associé à cette méthode qui est ajoutée dynamiquement sur un objet. Effectivement, là, oui faut pas abuser sur la meta-prog, ça peut mordre assez fort en cas d'erreur. Je ne trouve pas rare d'avoir à écrire des méthodes qui prennent des blocs en paramètre. Il se trouve que souvent, c'est sous la forme d'un bloc avec son yield, mais il arrive aussi d'avoir à manipuler directement les procs. Perso, si Ruby avait pas un support de première classe pour tout ça, je ne serais plus du tout aussi friand du langage. 2014-06-06 13:19 GMT+02:00 Sylvain Abélard <[email protected]>: > Bonjour, > > > j'essaye de mieux conprendre l'intéret que porte certaine personne au Proc. >> > Est-ce un troll ? :) > > *Je rappelle juste de la philosophie* > En terme de technique pure, de nombreux langages (y compris Java) font des > trucs comme ça. > Comparé avec les philosophies Ruby, finalement nous on les utilise plus > souvent. > Mais parfois pour faire n'importe quoi (cf failles de sécu sur de la > métaprog partout). > > *En très court, j'ai deux réponses :* > - quand tu en fais tu as l'impression d'être intelligent alors c'est cool > - des fois t'as vraiment pas le choix, mais quand t'as besoin de ça c'est > vraiment l'outil adapté > > > *En mode scientifique, j'en ai trois :*- c'est pratique pour embarquer > avec toi un traitement et aussi un environnement entier > > - c'est pratique pour les patterns Strategie et autres Visiteurs > https://github.com/nslocum/design-patterns-in-ruby#strategy > > http://stackoverflow.com/questions/1518474/visitor-pattern-in-ruby-or-just-use-a-block > > - c'est pratique pour du refactoring avec des pré- et post- traitements > similaires, > ou des traitements proches avec des "options de config" différentes (cf > Strategy) > > > > *En mode personnel, je suis "prudent".* > Je dirais que tu entendras que ce genre de code est plus "propre" ou > "élégant". > Je trouve ça subjectif : en réalité, quand tu écris de la belle > métaprogrammation et langage fonctionnel, tu es fier de toi, tu te sens > intelligent, alors tu es un peu arrogant et tu dis que c'est génial et il > faut en faire tout le temps. > > Moi j'ai quelques années de route au compteur, je me vante surtout d'être > pragmatique, alors je me contente de dire que quand tu te fais des gros > traitements, tu enchaînes des blocs et que : > - c'est facile à écrire : sorti de ton cerveau, les conditions et > traitements s'enchaînent, et ça marche, tout simplement > - c'est aussi et surtout, facile à lire : ton cerveau ne voit qu'une étape > simple à la fois, et peut aussi avoir l'ensemble des enchaînements sous les > yeux. > > Mais bon, ça c'est surtout un argument pour les blocs et la "saveur > fonctionnelle" de Ruby, car je n'utilise quasiment pas les Procs. > > > *Il faut juste se rappeler de l'historique.* > Tout d'abord, Ruby est un langage dynamique. > C'est là que se trouvent de nombreuses forces et faiblesses, et choses que > les gens aiment. > > Ruby permet aussi d'avoir une "saveur" fonctionnelle. > Je ne vais pas faire un cours sur le FP, mais après des années de > principes fonctionnels (et d'expérience) qui ont "infusé" en moi, je fais > du code avec des principes plus solides, qui tient dans la durée, que je > retouche moins, que j'ai moins de bugs surprenants, et que changer mon > archi se fait avec moins de douleur. > De nombreux Rubyistes ont soit changé de bateau vers du Haskell, Clojure, > Elixir... > Il y a des meetups : > http://functional-programming.meetup.com/cities/fr/paris/ > > Ces deux choses mènent aux blocs, que beaucoup de développeurs ont trouvés > confortables en arrivant à Ruby. > Ce sont des fonctions anonymes, que l'on compose à l'infini. > clients_a_relancer = clients.select{|c| c.avec_commande_non_validee? > }.sort{|x,y| x.last_connexion <=> y.last_connexion } > # exemple pas terrible mais bon > > > Mets tout ça ensemble (et surtout l'aspect ego, encore une fois) et ça > fait une sorte de fausse fascination sur les Proc. > En réalité c'est juste un outil de plus à ta dispo : c'est une bonne idée > de regarder et de garder ça sous le coude, mais ne tords pas tous les > problèmes pour y mettre du Proc. > > Voilà (c) > > À plus, > > -- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "RubyFR public". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected]. > Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse > [email protected]. > Visitez ce groupe à l'adresse http://groups.google.com/group/rubyfr-public > . > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- Jean-Hadrien Chabran -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
