Add a method to check for not nil
There does not seem to be a method in Ruby to check if an object is not nil.
Such a method could help with readability.
array = [1, 'dog', nil] array.count(&:not_nil?)
array = [1, 'dog', nil] array.reject(&:nil?).count
Updated by Hanmac (Hans Mackowiak) over 3 years ago
nobu (Nobuyoshi Nakada) wrote:
Hanmac (Hans Mackowiak) wrote:
does work for something similar like that.
IIRC, it equals to simple
are you sure? i am currently on ruby 2.3.3 Windows
[1, "bc", nil].count #=> 3 [1, "bc", nil].count(&:itself) #=> 2
Updated by ogarci5 (Oliver Garcia) over 3 years ago
What about as a condition for if statements? For example:
if !object.nil? # Do something end
if object # Do something end
if object.not_nil? # Do something end
I end up using Case 2 a lot because it reads better than Case 1. However this doesn't work if object can be false in which case Case 3 would be the most readable.
Updated by shevegen (Robert A. Heiler) over 3 years ago
I think that these discussions come up with some frequency; if I recall correctly,
Tsuyoshi Sawada was proposing something that I agreed with in principle. But I
did point out that the english language appears to have it easier with positive
assertions rather than negative ones.
I am not against
.not_nil? per se, mind you, since it may be symmetrical for
cases and the example give by darix (
unless nil?) but I think
it is something that is somewhat showing a limitation of the english language as
I actually found that the simplest way, for my own code, is to try to formulate
things "positively" whenever possible.
if condition end if condition1 and condition2 end
A similar explanation I use for
almost always go to pick exactly what I need to have.
Like a filter where you apply the filtering in a
forward fashion (you could of course always revert the
filter, like to use
.reject rather than
within the block clause, invert the checks).
To the suggestion itself in regards to
this may be worthwhile to have some special meaning for
what a user may want to count for.
In non-legal ruby, consider this:
array = [1, 'dog', nil] array.count(! &:nil?)
Granted, not very readable. :)
Then again, I also consider the & not really readable either.
array = [1, 'dog', nil] array.count(:not_nil)
To be honest, I don't think that these examples are really that
In the above example, using
.compact may be simpler:
For the latter, perhaps a method that does it, like .not_nil? but
I am not sure if this is used that much to warrant an addition.
I do somewhat agree with ogarci5 by the way - not necessarily because
of the explanation, but because in case 3 he gave, you do not have
to use "
unless" and neither the invert "operator" "
!", which is
usually much easier and more straightforward. So in that context,
I actually agree, having that flexibility may be a good thing,
even if I don't like the name
.not_nil? a lot.
I still think that it is a limitation of the english language.
Consider a backpack in a RPG/rogue-like game. You want to
query whether it is empty or filled:
if backpack.empty? # Seems simple. if !backpack.empty? # Seems ok although more difficult to understand if backpack.filled? # Hmmm... filled with what? if backpack.not_empty? # Not ideal but perhaps also better than the other two examples before
So I kinda semi-agree with ogarci5; I still think that the english language
itself is the one that has the biggest problems here with negations, followed
by the human brain modeling concepts. (OOP is a modeled concept too after all)
Updated by MSP-Greg (Greg L) about 3 years ago
I believe the english equivalent to
not_nil would be
exist (instead of exists, to follow prev use). I believe core only uses
Having it would allow showing the standard case first in an if-else-end structure, given that unless-else-end may be considered 'strange' code.
Also, I'm sure many of us have used a tri-state nil/false/true variable when it is helpful.