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#L16 false.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 rubyonrails-core+unsubscribe@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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Regardless of the merit (I don''t have a strong opinion on what is "correct" here), it''s 100% too big of a breaking change and it''s gonna break a lot of people''s app in some subtle but potentially very dangerous ways. -100 for me — Sent from Mailbox for iPhone On Thu, May 30, 2013 at 2:33 PM, Amitav Mohanty <amitavmohanty01@gmail.com> 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#L16 > false.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 rubyonrails-core+unsubscribe@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?hl=en. > 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+unsubscribe@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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Mohamed Wael Khobalatte
2013-May-30 22:35 UTC
Re: false.present? is false. Is it desired behaviour?
I agree with Godfrey. This is perhaps more of a semantic issue (A blank object is still present) and you are better off simply doing a quick nil? check. On Thu, May 30, 2013 at 11:33 PM, Godfrey Chan <godfreykfc@gmail.com> wrote:> Regardless of the merit (I don''t have a strong opinion on what is > "correct" here), it''s 100% too big of a breaking change and it''s gonna > break a lot of people''s app in some subtle but potentially very dangerous > ways. > > -100 for me > — > Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone > > > On Thu, May 30, 2013 at 2:33 PM, Amitav Mohanty <amitavmohanty01@gmail.com > > 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 rubyonrails-core+unsubscribe@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?hl=en >> . >> 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+unsubscribe@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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- Mohamed Wael Khobalatte -- 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+unsubscribe@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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
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 rubyonrails-core+unsubscribe@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.
Amitav Mohanty
2013-Jun-25 16:54 UTC
Re: Re: false.present? is false. Is it desired behaviour?
Hey On Tue, Jun 25, 2013 at 8:06 PM, James Pinto <tapgyn@gmail.com> wrote:> I understand where you''re coming from, > and I completely disagree > > false is blank, but it''s not nil, >Well I think since it is a value, it should not be considered blank.> however, in some cases, falseness should not be validated >And in some cases, it might be required to be validate that. This is a case to case approach and for some people a certain set of cases might be relevant while another set of cases might be relevant for some others. After I posted this issue, I have encountered another issue in our system related to this. So, for my setup the validation makes sense.> > "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] >Please refer to http://intosimple.blogspot.**in/2013/05/rails-falsepresent-* *being-false-is-not.html for a sample case. The above example is obvious from the source code investigation I provide in the link. 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 rubyonrails-core+unsubscribe@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.
Matt Jones
2013-Jun-25 17:10 UTC
Re: Re: false.present? is false. Is it desired behaviour?
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 markIf 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+unsubscribe@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
2013-Jun-26 16:34 UTC
Re: Re: false.present? is false. Is it desired behaviour?
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. On Tue, Jun 25, 2013 at 7:10 PM, Matt Jones <al2o3cr@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+unsubscribe@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 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+unsubscribe@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.
Amitav Mohanty
2013-Jun-27 11:17 UTC
Re: Re: false.present? is false. Is it desired behaviour?
Hey On Wed, Jun 26, 2013 at 10:04 PM, Piotr Sarnacki <drogus@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 <al2o3cr@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+unsubscribe@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+unsubscribe@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+unsubscribe@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.
Carlos Antonio da Silva
2013-Jun-27 12:20 UTC
Re: Re: false.present? is false. Is it desired behaviour?
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 <amitavmohanty01@gmail.com>wrote:> Hey > > On Wed, Jun 26, 2013 at 10:04 PM, Piotr Sarnacki <drogus@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 <al2o3cr@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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.