Allez, je balance ma version. SI tu as appris la prog a l'ecole francaise, on tauras explique qu'il y a 2 types majeurs en prog. Les donnees et la logique (les traitements). En realite, nombreux sont ceux qui concoivent les traitements comme un type de donnes comme un autre.
Proc est un conteneur de traitement, ni plus ni moins. Cela permet d'ecrire des algos puissants qui reposent sur le resultat d'un traitement arbitraite qui leur sera fourni en parametre au moment de leur execution. Cela delegue la responsabilite du traitement a l'appelant au lieu de devoir gerer ca avec de l'heritage ou de la composition ou de la decoration. Enumerable est un tres bon exemple de ca. Si tu voulais implementer un map/reduce en java, tu devrais heriter ou decorer, donc ecrire beaucoup plus de code pour faire quelque chose de simple (avant quils ajoutent les fonctions anonymes) Enfin, ruby apporte quelques methodes pour mieux controller le contexte d'execution des blocks (class, instance et autres eval...) ce qui rend leur utilisation beaucoup plus intuitives que les fonctions js et leur proxy pas beau. Voila. Next :) On Jun 6, 2014 7:19 PM, "Sylvain Abélard" <[email protected]> wrote: > 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 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 obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- 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 .
