2009-09-16 9 views

Répondre

5

Pourquoi dans les webapps en particulier? Voulez-vous dire le cadre Ruby on Rails, peut-être?

Les processus et les lambdas sont utiles lorsque vous souhaitez stocker des parties de code de manière anonyme. Procs et lambdas sont très similaires aux méthodes, sauf qu'ils n'ont pas de nom. Un bon exemple pour illustrer cela, dans ActiveRecord/Rails:

// methods are named 
validates_presence_of :foo, :if => :active? 

// procs aren't 
validates_presence_of :foo, :if => proc {|r| do_stuff } 

I général, procs sont utilisés pour callbacks et crochets, de sorte que vous n'avez pas à écrire des méthodes nommées et les consulter, mettre le code question directement dans les hachages d'option et autres. Vous pouvez trouver this article utile.

+0

Merci pour le lien. Non, je ne voulais pas dire ROR. Je voulais juste dire des exemples typiques de tous les jours où vous pourriez utiliser procs/lambdas - comme dans les applications web. Désolé si je n'étais pas clair. – uzo

3

je les utiliser sur les champs nommés:

named_scope: dernière, lambda {| quantité | {: Order => "created_at DESC",: limit => quantité}}

Pour créer un moyen facile d'obtenir les derniers messages numériques, commentaires, etc.

Maintenant, je peu il triché, il est plus d'une chose cadre que d'une "application web", mais je ne peux pas penser que l'application web est si différente des autres applications de bureau. Les deux procs et Lambdas vous permettent de "sauver" le code pour une utilisation ultérieure, et peuvent aider à utiliser le comportement, utiliser plus de méthodes "orientées domaine" et nettoyer un peu plus de "code régulier"

1

L'utilisation de lambda ou proc est une question de style de programmation appelée programmation fonctionnelle. Il y a plusieurs interfaces Rails où vous voudrez peut-être passer un objet bloc (lambda ou PROCC), tout comme validations:

class Person < ActiveRecord::Base 
    validates_acceptance_of :terms_of_service :if => Proc.new { |user| user.signup_step > 2 } 
end 

Vous pouvez concevoir des interfaces comme ça, où vous pouvez donner à l'utilisateur le choix de passer un nom de méthode (symbole) ou un objet proc (ou lambda) pour spécifier une certaine logique.

Un autre endroit dans Rails par exemple est où vous pouvez définir layouts dynamiquement:

class WeblogController < ActionController::Base 
    layout proc{ |controller| current_user.logged_in? ? "writer_layout" : "reader_layout" } 
end 
1

De toute évidence, procs et lambdas sont un élément essentiel de tout ce qui concerne les callbacks, mais dans la plupart des cas en ruby ​​cela peut être accompli avec un bloc.

Un endroit où les procs ou lambdas sont utiles et qui n'est pas lié aux callbacks est comme compiler une expression régulière. Bien sûr, regex fait partie du langage, donc vous n'avez pas besoin de procs pour cela, mais vous pouvez vous retrouver à écrire un autre type de procédure qui a un coût unique qui peut être réutilisé, mais qui ne vaut pas vraiment la peine d'être créé une classe complète.

Dans mon cas, j'avais un objet (publist) qui contenait une liste de chaînes. Dans une zone du code, j'avais besoin de vérifier à plusieurs reprises si un autre ensemble avait des membres dans cette liste. Cela aurait été gênant et aurait eu de mauvaises performances pour changer le type de données afin que l'objet contienne un ensemble. Donc ce que j'ai fait était de créer une méthode qui renvoyait un matcher lambda qui avait une représentation locale de cette liste.

J'aurais pu renvoyer un ensemble, mais la logique métier de savoir si un élément correspondait logiquement appartenait au publist.Je pourrais à l'avenir changer cela pour prendre en charge des sous-chaînes ou des expressions régulières et les utilisateurs du matcher auraient toujours la même API.

Questions connexes