Re: [Rails-core] false.present? is false. Is it desired behaviour?

[Godfrey Chan]

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 <amitavm...@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-co...@googlegroups.com.
To post to this group, send email to rubyonra...@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]

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. 

--
Mohamed Wael Khobalatte

[James Pinto]

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]

[Amitav Mohanty]

Hey

On Tue, Jun 25, 2013 at 8:06 PM, James Pinto <tap...@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

[Matt Jones]

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

[Piotr Sarnacki]

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.

--
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-co...@googlegroups.com.
To post to this group, send email to rubyonra...@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

[Amitav Mohanty]

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 <al2...@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-co...@googlegroups.com.

To post to this group, send email to rubyonra...@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-co...@googlegroups.com.

[Carlos Antonio da Silva]

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 :)

At.
Carlos Antonio