3 ms·

It's arguable whether NilClass#blank? is very-useful (the same can be said for #to_a, #to_c, #to_f, #to_h, #to_i, #to_r, and #to_s). I'd call it marginally con

by spoiler 11y ago

It's arguable whether NilClass#blank? is very-useful (the same can be said for #to_a, #to_c, #to_f, #to_h, #to_i, #to_r, and #to_s). I'd call it marginally convenient, because you have to type less, but it doesn't increase usability, and the readability is pretty much the same (or worse, because someone would have to know NilClass responds to blank?, if they don't they might've expected an empty array, or an empty string). Also, why does FalseClass respond to blank? with `true`, but not TrueClass (I didn't know it did this for those two until now)? How is false less blank than true?

pdkl95 11y ago
NilClaass#blank? is incredibly useful because it compliments String#blank? and Array#blank?, which are mostly[1] an alias of #empty?. For most uses where you already know you have a string or array, you probably want to use #empty? directly. The entire point behind #blank? is that it provides a cross-class[2] method that works even when the object doesn't exist (and you get nil instead). This was designed for Rails to simplify situations such as the params[3] (parsed URL query string), which might not have a particular value. # when handling "/action?foo=bar" params[:foo] # => "bar" # when handling "/action?foo=" params[:foo] # => "" # when handling "/action" params[:foo] # => nil With #blank?, you only need one function call to handle both the empty string and nil cases. if params[:foo].blank? # render a static placeholder (never looks at params) else # render Foo's markup, using the value in params[:foo] end If you cared about the empty states other than as a generic "it's blank", other methods may be more appropriate. > why does FalseClass respond to blank? with `true`, but not TrueClass That's a good question. I would have assumed both true and false as not-blank (#blank? => false), as those could both be entered (#present?) values. I suspect it's related to HTML forms only including successful controls[4] in the query string. [1] https://github.com/rails/docrails/blob/master/activesupport/lib/active_support/core_ext/object/blank.rb#L100 https://github.com/rails/docrails/blob/master/activesupport/... [2] see: duck-typing [3] http://api.rubyonrails.org/classes/ActionController/Parameters.html http://api.rubyonrails.org/classes/ActionController/Paramete... [4] http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.2 http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.2
- spoiler 11y ago
  I am aware of where it's used, and I am aware it can be convenient, although I am not very enthusiastic about using it. > I suspect it's related to HTML forms only including successful controls Yeah, this is a good point, since an unchecked checkbox isn't transmitted in a standard HTML form, but Rails does add a hidden input element with the value false; so I guess #blank? does somewhat increase readability here, but this could've and should've been fixed in a better way (a few ideas come to mind). Don't get me wrong, I probably used #blank? (and might in the future) just for the sake of convenience. However, it makes me feel guilty when I do, because it could subtly introduce and hide bugs due to lack of more adequate checks.

by spoiler 11y ago

pdkl95 11y ago

NilClaass#blank? is incredibly useful because it compliments String#blank? and Array#blank?, which are mostly[1] an alias of #empty?. For most uses where you already know you have a string or array, you probably want to use #empty? directly. The entire point behind #blank? is that it provides a cross-class[2] method that works even when the object doesn't exist (and you get nil instead). This was designed for Rails to simplify situations such as the params[3] (parsed URL query string), which might not have a particular value. # when handling "/action?foo=bar" params[:foo] # => "bar" # when handling "/action?foo=" params[:foo] # => "" # when handling "/action" params[:foo] # => nil With #blank?, you only need one function call to handle both the empty string and nil cases. if params[:foo].blank? # render a static placeholder (never looks at params) else # render Foo's markup, using the value in params[:foo] end If you cared about the empty states other than as a generic "it's blank", other methods may be more appropriate. > why does FalseClass respond to blank? with `true`, but not TrueClass That's a good question. I would have assumed both true and false as not-blank (#blank? => false), as those could both be entered (#present?) values. I suspect it's related to HTML forms only including successful controls[4] in the query string. [1] https://github.com/rails/docrails/blob/master/activesupport/lib/active_support/core_ext/object/blank.rb#L100 https://github.com/rails/docrails/blob/master/activesupport/... [2] see: duck-typing [3] http://api.rubyonrails.org/classes/ActionController/Parameters.html http://api.rubyonrails.org/classes/ActionController/Paramete... [4] http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.2 http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.2

spoiler 11y ago
I am aware of where it's used, and I am aware it can be convenient, although I am not very enthusiastic about using it. > I suspect it's related to HTML forms only including successful controls Yeah, this is a good point, since an unchecked checkbox isn't transmitted in a standard HTML form, but Rails does add a hidden input element with the value false; so I guess #blank? does somewhat increase readability here, but this could've and should've been fixed in a better way (a few ideas come to mind). Don't get me wrong, I probably used #blank? (and might in the future) just for the sake of convenience. However, it makes me feel guilty when I do, because it could subtly introduce and hide bugs due to lack of more adequate checks.