My biggest concern with nonblank? is that idiomatic Ruby is to return a boolean from question mark methods. I like Pratik's solution, and would like to see a scenario where the short-circuit logic is important (and common enough to justify an core class extension).
Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 On Sun, Dec 27, 2009 at 10:43 AM, Duncan Beevers <[email protected]> wrote: > > Including all the items in an Array and picking the first present one circumvents any opportunity to use logic short-circuiting to avoid unnecessary, potentially expensive calculation, not to mention unnecessary allocation of container objects and the overhead of symbol-to-proc. > > +1 for nonblank? > > On Sun, Dec 27, 2009 at 9:19 AM, Pratik <[email protected]> wrote: >> >> I see. But it does feel like code smell to me. And, you can always do >> something like : >> >> region = [params[:state], params[:country], 'US'].detect(&:present?) >> >> On Sun, Dec 27, 2009 at 10:28 PM, ColinDKelley <[email protected]> wrote: >> >> We already have Object#present? :) >> > >> > True, but present? is just the inverse of blank?. What we've found >> > very useful is to have a method that treats blank parameters the same >> > as missing ones, and allows chaining. >> > >> > Check out the example: >> > >> > state = params[:state] unless params[:state].blank? >> > country = params[:country] unless params[:country].blank? >> > region = state || country || 'US' >> > >> > Rewriting with present? isn't any more expressive: >> > >> > state = params[:state] if params[:state].present? >> > country = params[:country] if params[:country].present? >> > region = state || country || 'US' >> > >> > But nonblank? makes it more concise and expressive IMO: >> > >> > region = params[:state].nonblank? || params[:country].nonblank? || >> > 'US' >> > >> > We've been using it this way for the last year and it really has >> > cleaned up a lot of code. More importantly it has become a reflex to >> > use it inline--as shown above--that has helped us avoid bugs where we >> > might think a parameter was present but really it was just there with >> > an empty value. >> > >> > I suppose we could keep the method name present? but switch its >> > behavior to match what's proposed here for nonblank?. But that >> > contract change could break someone's code who was depending on a >> > boolean being returned. Also I prefer that nonblank? has a name that >> > parallels nonzero? from Ruby. >> > >> > I like the symmetrical pair of nonzero? and nonblank? because they map >> > values (0, empty/blank string respectively) to nil that are typically >> > equivalent to not being present at all. Other languages like Python >> > found it convenient to have 0 and empty string treated as false for >> > just this reason I think. >> > >> > -Colin >> > >> > >> > On Dec 27, 5:37 am, Pratik <[email protected]> wrote: >> >> We already have Object#present? :) >> >> >> >> >> >> >> >> >> >> >> >> On Sun, Dec 27, 2009 at 7:49 AM, ColinDKelley <[email protected]> wrote: >> >> > All, >> >> >> >> > I'd like to propose the Object#nonblank? in ActiveSupport, layered >> >> > over the blank? method. This has been working well for us in the past >> >> > year and hopefully others will find it useful enough to include in >> >> > core. >> >> >> >> > It is analogous to Ruby's Numeric#nonzero? method: it either returns >> >> > the object itself (if not blank) or nil (if blank). This makes it easy >> >> > to treat blank parameters the same as missing ones, and allows >> >> > chaining: >> >> >> >> > For example, this: >> >> >> >> > state = params[:state] unless params[:state].blank? >> >> > country = params[:country] unless params[:country].blank? >> >> > region = state || country || 'US' >> >> >> >> > becomes: >> >> >> >> > region = params[:state].nonblank? || params[:country].nonblank? || >> >> > 'US' >> >> >> >> > The ticket is here: >> >> >> >> > https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3... >> >> >> >> > along with a patch that includes full documentation and tests. >> >> >> >> > -- >> >> >> >> > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> >> > To post to this group, send email to [email protected]. >> >> > To unsubscribe from this group, send email to [email protected]<rubyonrails-core%[email protected]> . >> >> > For more options, visit this group athttp:// groups.google.com/group/rubyonrails-core?hl=en. >> >> >> >> -- >> >> Cheers! >> >> - Pratikhttp://m.onkey.org|http://twitter.com/lifo >> > >> > -- >> > >> > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to [email protected]<rubyonrails-core%[email protected]> . >> > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >> > >> > >> > >> >> >> >> -- >> Cheers! >> - Pratik >> http://m.onkey.org | http://twitter.com/lifo >> >> -- >> >> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to [email protected]<rubyonrails-core%[email protected]> . >> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > > -- > > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]<rubyonrails-core%[email protected]> . > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en.
