As you can see here: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/object/blank.rb#L55, blank? is also implemented in FalseClass to always return true, so yes, it was deliberate :)
On Thu, Jun 27, 2013 at 8:17 AM, Amitav Mohanty <amitavmohant...@gmail.com>wrote: > Hey > > On Wed, Jun 26, 2013 at 10:04 PM, Piotr Sarnacki <dro...@gmail.com> wrote: > >> While technically you could say that "false" is "present", it would be >> really unintuitive for most of the people as present? is supposed to be >> just opposite of blank? and is used to check for truthiness. Additionally >> present? is used in Rails app for a long time, so even if part of Rails >> Core had agreed with your arguments, I would be really surprised seeing >> this changed. >> > > To analyze the cause, I had looked at the definition of blank? > > def blank? > respond_to?(:empty?) ? empty? : !self > end > > Since false does not respond to :empty?, it seems to be false being blank > is just a by-product of the "!self" part of the function definition. What I > wanted to understand is whether this was deliberate. > > Regards, > Amitav > > >> >> >> On Tue, Jun 25, 2013 at 7:10 PM, Matt Jones <al2o...@gmail.com> wrote: >> >>> >>> On Jun 25, 2013, at 7:36 AM, James Pinto wrote: >>> >>> 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* >>> >>> >>> If it's OK if the user doesn't send this value, *why* are you validating >>> for it to be present? Set a default for your boolean column (which you >>> should be doing anyways :) ) and have a nice life. >>> >>> --Matt Jones >>> >>> >>> -- >>> 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 rubyonrails-core+unsubscr...@googlegroups.com. >>> >>> To post to this group, send email to rubyonrails-core@googlegroups.com. >>> Visit this group at http://groups.google.com/group/rubyonrails-core. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> >> >> -- >> Piotr Sarnacki >> http://piotrsarnacki.com >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Ruby on Rails: Core" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/rubyonrails-core/A-1oZuShUaM/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> rubyonrails-core+unsubscr...@googlegroups.com. >> >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > 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 rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- At. Carlos Antonio -- 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 rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
