This project is archived and is in readonly mode.
errors.on(:att) should not return a String
-
Xavier Shay
yes please, I hate the previous behavior. I want it to return an empty array rather than nil also, but that would probably break too much stuff
-
Justin French
yeah, i'd love an empty array too, and i started on that too, but I see a lot of code checking 'errors.on(:foo)' rather than 'errors.on(:foo).blank?'
-
DHH
- State changed from new to hold
This is not going to be backwards compatible and I'm sorta on the fence about whether it's even a good idea. If you're primarily working with 1 error per field, it'd be a hassle to deal with the array. And if you are thinking there might be multiple, couldn't you just wrap the call in Array()?
-
Justin French
I agree this isn't just a quick patch we can squeeze into stable any time we like, but I just don't buy the idea that most people, most of the time will only have or expect one error on a field. Nor can I buy the idea that they'd expect a String instead of an array for a pluralized method name like
errors.And (aside from unit tests) it's not THAT much of a compatibility problem, is it? For those that were expecting a string Array#to_s returns the string, and to_s is called by ERB.
I've seen plenty of developers have a "WTF?" moment on this. They all expected an array of one object. Hey, they all expected an empty array for zero errors too, so let's fix that!
Major releases like 3.0 are an opportunity to reduce those WTF moments.
-
Jonas Schneider
+1 for me, for sure. stumbled across this stuff so many times now... But it should be included first in Rails3 or something (where we break bc anyway :D)
