We're talking about a "fluent interface" here. ( http://martinfowler.com/bliki/FluentInterface.html). The Ruby implementation is indeed quite simple: return self. Here's an example from another project of mine: http://github.com/primedia/endeca/blob/c5f307a3711186831ec6766e25ba4b5beff36e54/lib/endeca/map.rb I think it's a good idea for some of the internal Puppet DSLs, but it isn't a one-size-fits all solution. We should look for situations where chaining method calls to accumulate object state is a useful mechanism. It's also important that the object not be "incomplete" at any point. If that's the case, a block constructor pattern is more appropriate.
On Tue, Sep 8, 2009 at 8:39 PM, Luke Kanies <[email protected]> wrote: > > On Sep 8, 2009, at 12:29 PM, Steven Jenkins wrote: > > > > > Luke Kanies wrote: > > ... > >>> Note that Rails also uses this style; e.g., it's common to see > >>> things like > >>> > >>> total = Product.find(product_list).sum(&:price) > >> > >> This isn't a terribly good example (since Product.find returns an > >> instance of Product and then sum returns a number), but I understand > >> what you mean. > >> > >>> where the result of one method is the object that is used for the > >>> subsequent method. > >>> > >>> I haven't looked all through the Puppet source for this, but, yes, > >>> it would be > >>> good to be done everywhere, not just this one file. It would be a > >>> technically > >>> straightforward task to do (just tedious). I'd suggest either > >>> putting together > >>> a set of Redmine tasks, and perhaps to put it aside and apply for a > >>> Google > >>> Summer of Code student next year if no one has gotten to it by Feb/ > >>> March. > >> > >> I guess my main question is when this would be used, but I suppose > >> it's 'any method whose return you don't care about'? > >> > > > > Would it be more clear to say it is "any method who is not > > necessarily returning > > some new kind of value but is mainly used for its side-effects'. > > > I agree. > > I've asked Markus to create a 'Puppet Refactorings' wiki page, where > we can document ideas like this. There are a lot of aspects of Puppet > that should be refactored, either in small or large part, and having a > standard list of "fix these if you see them" is a good idea. > > -- > I can win an argument on any topic, against any opponent. People know > this, and steer clear of me at parties. Often, as a sign of their > great respect, they don't even invite me. -- Dave Barry > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > > > -- Rein Henrichs http://reductivelabs.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
