Josh, I agree that this usage comes up often in controllers, but it is common in models too. It seems to me that this issue comes up any time you want to map the "empty"/"blank" value to be the same as the "not present" value, whether those came from a form, the database, or read from a file... Yes, if Ruby had chosen empty strings to be false- ish (like Perl & Python) that would have helped.
Numeric is exactly parallel, where it's often appropriate to map 0 to be the same as the "not present" value, nil. nonzero? does that, which can make up for the fact that Ruby considers 0 to be true-ish. (BTW whenever possible we choose our string attributes to be null => false in the DB so we don't have to write code that deals with two types of empty. Of course there are cases when you really want a blank/empty string to be one kind of empty and nil/NULL to be another, but that is << 1% case IME.) Do Rails forms have any convention for posting the "nil" value? They've now got the special _delete key for nested forms. It seems like it would be valuable to have a similar special representation to indicate that a column should be set to nil. (We were doing some composed_of attributes last month and really would have found that handy. Instead we have ugliness in our controller to impose a convention like that on the params values before updating the model.) -Colin On Dec 28, 10:04 am, Josh Susser <[email protected]> wrote: > This whole discussion is caused by the way Rails handles form > submissions of text fields. If a user enters no value, the controller > action gets a param that is an empty string instead of nil. That's > probably the simplest thing to do in most cases, but the implication > is that model attributes will have empty strings instead of nil in the > record. That means you can't do the idiomatic Ruby: > > user.nickname || user.name > > Now we have #presence which lets us do: > > user.nickname.presence || user.name > > That's reasonably concise, but just keep in mind that all of this is > just to make Ruby act more like Perl where empty strings are false-ish > values. I'm sure there are other use cases for #presence, but empty > strings that come from form submissions seem like at least 90% of the > issue. > > --josh > > On Dec 28, 2009, at 7:07 AM, Rick DeNatale wrote: > > > > > > > On Sun, Dec 27, 2009 at 2:51 PM, Yehuda Katz <[email protected]> wrote: > >> 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 > > > Well IMHO, I think it's more idiomatic Ruby to have a predicate only > > worry about the truthiness or falsiness of what it returns. Any value > > other than nil or false is a perfectly good, and true return value > > from a predicate, and in many cases more useful. > > > Insisting that a predicate return either true or false, smells more > > Java or C++ish than Rubyish to me. > > > But what do I know? > > > -- > > Rick DeNatale > > > Blog:http://talklikeaduck.denhaven2.com/ > > Twitter:http://twitter.com/RickDeNatale > > WWR:http://www.workingwithrails.com/person/9021-rick-denatale > > LinkedIn:http://www.linkedin.com/in/rickdenatale > > > -- > > > 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 > > athttp://groups.google.com/group/rubyonrails-core?hl=en > > . > > -- > Josh Susserhttp://blog.hasmanythrough.com -- 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.
