Hello:
1.9.3p194 :014 > “”.blank?
=> true
1.9.3p194 :015 > [“”, “”].blank?
=> false
Proposal: the second line should also produce true.
Thoughts?
The array has objects on it, so it isn't blank.
Michael,
That array isn’t blank, empty strings aren’t the same as nils. I think changing that behavior would be confusing. If you don’t want to count those elements, it’s probably best to filter the array for non-blank strings.
-Geoff
If you really want to check for "are all the values in this array blank", try:
some_array.all?(&:blank?)
--Matt Jones
Geoff,
But from the Rails documentation: An object is blank if it’s false, empty, or a whitespace string. For example, “”, “ ”, nil, , and {} are all blank. That’s why I think an array full of false, empty, or whitespace strings should be empty.
- Michael
Empty means that it has no elements.
Why? [“”] is not an empty array.
Maybe this description may help?
http://guides.rubyonrails.org/active_support_core_extensions.html#blank-and-present
An object is blank if it’s false, empty, or a whitespace string. For example, “”, “ ”,
nil, , and {} are > all blank. That’s why I think an array full of false, empty, or whitespace strings should be empty.
But that’s not mathematically accurate.
“”.size #=> 0
[“”].size #=> 1
[nil].size #=> 1
An array with a single item is no longer empty, even if the item itself is empty.
Sorry, where I last wrote “empty” I meant to write “blank,” ie: That’s why I think an array full of false, empty, or whitespace strings should be blank. Rails defines blank as a convenience method instead of checking if something is nil and then if it’s empty or not. I think extending that convenience to arrays makes sense. To clarify:
[“”, “”].empty? # false [“”, “”].blank? # true
- Michael
Ah, OK. So the definition of blank? is clear but you are proposing to change it for Arrays right?
Blank is a convenience method for not checking the type of object. If you want to do that you should use:
array.all?(&:blank)
Yes.
That’s very unlikely to happen. Pretty much all Rails app rely on this behavior.
Your implementation makes sense. I mean, I believe that if blank? was defined on enumerables as all?(&:blank?) from the very first day, one could have accepted that definition just fine.
But the current definition also makes sense to me.
Since this is a fundamental predicate in Active Support that has had this semantic since forever, this modification would be backwards incompatible, and the current definition is also just fine in my opinion, I think we should keep it the way it is.
Yes, we need #blank? to be extra expensive because beginners needn’t control what gets injected in their Arrays. Maybe {"" => ""}.blank? should be true, too?
Here you go:
class Array
def super_blank?
Go!
end
end
Scott
Lock down your data at the gates and this is not a problem. Making #blank? incredibly slow is silly.
Do you think anyone currently uses #blank? on enumerables in its current state? It doesn’t make sense the way it is right now. Imagine a piece of paper with a list of 10 blank lines. Wouldn’t you call that a blank list?
I don’t think that blank? makes sense on anything other than String, no matter how you define it. My vote would be to deprecate it on Enumerable, for example, and add something else if desired.
James Coleman
Yes, I think everyone uses #blank? on enumerables in its current state, and expect that behavior, because it is well documented.
Rafael Mendonça França http://twitter.com/rafaelfranca
