I understand where you're coming from,
and I completely disagree

false is blank, but it's not nil,
however, in some cases, falseness should not be validated

"validates_presence_of :aggrees_with_contract"* is correct, requires the 
user to check the contract*
"validates_presence_of :displays_photo_for_guests" *is incorrect, because 
it's only a question and it's ok if the user forgets or chooses not to mark*


[false, nil].map &:blank?
=> [true, true]
[false, nil].map &:present?
=> [false, false]
[false, nil].map &:nil?
=> [false, true]






On Thursday, May 30, 2013 5:31:30 PM UTC-4, Amitav Mohanty wrote:
>
> Hey
>
> I initially posted this idea on Github where I was suggested by Steve to 
> post it here. The idea is as follows.
>
> With the current definition of blank? as defined in 
> https://github.com/rails/rails/blob/2a371368c91789a4d689d6a84eb20b238c37678a/activesupport/lib/active_support/core_ext/object/blank.rb#L16false.present?
>  returns false. The documentation mentions it clearly too. 
> However, I was of the opinion that a value of false is still a value and 
> there probably should return true when checked for presence.
>
> When an array is empty, it does not contain any valid values and thus is 
> blank. However, false is a valid value for a boolean variable. So, probably 
> false.present? should not be false.
>
> This is of course just my opinion. I know I can always check for nil?. If 
> there are valid scenarios where false.present? returning a value of false 
> is useful/intuitive, I would be glad to know.
>
> I have explained at 
> http://intosimple.blogspot.in/2013/05/rails-falsepresent-being-false-is-not.html
>  one scenario where I thought false.present? returning true would have 
> been more intuitive. Please have a look and let me know your ideas.
>
> Thanks and regards,
> Amitav
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to