I've also been adding a nonblank? method as soon as I find it useful on a project.
As for predicate methods returning true or false, the Numeric#nonzero? to which the OP compares nonblank? is a perfect counter example. The way that it was explained to me (by Jim Weirich, iirc) was that a predicate should return either false/true or nil/"not nil" (where "not nil" is typically a useful object). This is precisely how Numeric#nonzero? behaves. I like nonblank? for the same reason that I dislike present? -- I *know* that " ".blank? is true, but " ".present? doesn't strike me as necessarily false like " ".nonblank? does. -Rob On Dec 27, 2009, at 3:20 PM, Xavier Noria wrote: > A predicate returns a true or false value. Albeit an implementation > may choose some particular true or false value for convenience, I > think it is not a good practice for client code to depend on it. > > I am -1 because I think a predicate should document only a boolean > contract. > > On the other hand it is something you can easily add to your app, as > you've been doing. > > Sent from my iPhone > > El 27/12/2009, a las 17:58, ColinDKelley <[email protected]> > escribió: > >>> 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] >>>> . >>>> 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 rubyonrails- >> [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 >> . >> >> > > -- > > 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 rubyonrails- > [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 > . > > -- 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.
