Proposal for nil, 0, and "" in an if statement

[Dan Fitzpatrick]

The following was derived from a portion of the destrutive! operations
thread.

Here is a proposal for evaluating "", 0, and nil in an if statement:

Add empty? to NilClass and Fixnum

class NilClass
def empty?
true
end
end

class Fixnum
def empty?
self == 0 ? true : false
end
end

nil.empty? => true
0.empty? => true

These already exist:
"".empty? => true
[].empty? => true
{}.empty? => true

Dan

 

[Bertram Scharpf]

Hi,

Am Dienstag, 22. Feb 2005, 20:49:51 +0900 schrieb Dan Fitzpatrick:

The following was derived from a portion of the destrutive! operations
thread.

Here is a proposal for evaluating "", 0, and nil in an if statement:

Add empty? to NilClass and Fixnum

nil.empty? => true
0.empty? => true

These already exist:
"".empty? => true
[].empty? => true
{}.empty? => true

Maybe even "true.empty? #=> true", "false.empty? #=> false"?

A good chance to end the discussions started over and over
about strings and numbers in `if' clauses, I think.

Bertram

 

[Dan Fitzpatrick]

--------------050603040304090209060501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Am Dienstag, 22. Feb 2005, 20:49:51 +0900 schrieb Dan Fitzpatrick:

The following was derived from a portion of the destrutive! operations
thread.

Here is a proposal for evaluating "", 0, and nil in an if statement:

Add empty? to NilClass and Fixnum

nil.empty? => true
0.empty? => true

These already exist:
"".empty? => true
[].empty? => true
{}.empty? => true

Maybe even "true.empty? #=> true", "false.empty? #=> false"?

A good chance to end the discussions started over and over
about strings and numbers in `if' clauses, I think.

Bertram

I would reverse the true and false:

true.empty? => false
false.empty? => true

These are not quite as intuitive as NilClass and Fixnum but I agree they would be nice to have as well.

Dan




--------------050603040304090209060501--

 

[David Heinemeier Hansson]

Here is a proposal for evaluating "", 0, and nil in an if statement:

I'd be pretty happy to see that happen. It would make especially Ruby
in view logic a lot easier to deal with.

 

[Michael Neumann]

I'd be pretty happy to see that happen. It would make especially Ruby in
view logic a lot easier to deal with.

But please please use a different name than "empty?", maybe "nothing?"
or "something?" or whatever else.

Regards,

Michael

 

[Pit Capitain]

I'd be pretty happy to see that happen. It would make especially Ruby in
view logic a lot easier to deal with.

Could anyone post examples of actual code that would be easier if 0 had a
special property in common with nil and ""? I think I never needed this in Ruby.

Regards,
Pit

 

[Gavin Kistner]

Could anyone post examples of actual code that would be easier if 0
had a special property in common with nil and ""? I think I never
needed this in Ruby.

I don't have actual code, but imagine looping through records returned
with financial data, and you want to print out a "-" if the field is
missing -or- zero. The whole "this field doesn't have any meaningful
information that contributes to the sum of the column" spreadsheet
thing.

I would support an RCR with this proposal, under just about any method
name
And I agree, boolean types need the same method as well.

 

[Gavin Kistner]

I would support an RCR with this proposal, under just about any method
name

As I responded in the destructive! thread, if people are opposed to the
term "empty?", then what about the sort of fun name of "vapid?"
instead?

vap-id
adj.
1. Lacking liveliness, animation, or interest; dull: vapid
conversation.
2. Lacking taste, zest, or flavor; flat: vapid beer.

We're not actually denigrating the value so far as to call it empty or
useless, but simply stating that it's one that we commonly aren't
interested in. (Although to be precise, I suppose we tend to be
interested in these values specifically because they are so different
from all the others...it's just that it's only the others that we care
about

0.vapid? #=> true
"".vapid? #=> true
[].vapid? #=> true
{}.vapid? #=> true
false.vapid? #=> true
nil.vapid? #=> true

 

[David A. Black]

Hi --

As I responded in the destructive! thread, if people are opposed to the term
"empty?", then what about the sort of fun name of "vapid?" instead?

It's arguably exactly the opposite of what you'd want -- namely, to
point up the singularity of 0/""/etc., not their ordinariness. 37534
is more vapid than 0

I'm not sold on this anyway. I think it would have the flavor of
"added on to the language as an afterthought". .zero? means the
object is zero, and .empty? means a container object is empty. I
don't think cross-breeding them retains the logic.


David

 

[Peter Hickman]

I don't have actual code, but imagine looping through records returned
with financial data, and you want to print out a "-" if the field is
missing -or- zero. The whole "this field doesn't have any meaningful
information that contributes to the sum of the column" spreadsheet thing.

Might this not cause trouble with databases. A database record (returned
as a structure or object) would have NULL == nil for fields with no
value which is not the same as a field with a definite value such as 0.

 

[Michael Neumann]

Hi --




It's arguably exactly the opposite of what you'd want -- namely, to
point up the singularity of 0/""/etc., not their ordinariness. 37534
is more vapid than 0

I'm not sold on this anyway. I think it would have the flavor of
"added on to the language as an afterthought". .zero? means the
object is zero, and .empty? means a container object is empty. I
don't think cross-breeding them retains the logic.

100% agree. I especially cannot understand (at least mathematically) why
0 would be empty and 1 not.

Why not simply define a has_value? method:

def has_value?(obj)
case obj
when Enumerable
!obj.empty?
when NilClass, FalseClass
false
when TrueClass
true
when Integer
!obj.zero?
else
# do what you want
obj.respond_to?(...)
...
end
end

This probably serves most needs...

Regards,

Michael

 

[Gavin Kistner]

Yes, there are many cases where you DO want to distinguish between nil
and 0. These cases are already handled by the current behavior of
Ruby.

To be clear - the proposal is NOT to make Ruby act like one of the many
other languages where "", 0 and friends are treated as non-truth values
in boolean expressions. The proposal is simply to add an additional
method to all that allows a programmer to treat them the same in the
few cases where that is desirable.

 

[Peter Hickman]

To be clear - the proposal is NOT to make Ruby act like one of the
many other languages where "", 0 and friends are treated as non-truth
values in boolean expressions. The proposal is simply to add an
additional method to all that allows a programmer to treat them the
same in the few cases where that is desirable.

As long as we are only proposing to add a new method then I am happy but
to be honest I think that the utility of this method will be very small
and the potential for confusion big. The difference will be subtle and
only visible in particular situations. I expect that it could become a
gotcha very quickly.

 

[Nikolai Weibull]

* Dan Fitzpatrick (Feb 22, 2005 14:00):

true.empty? => false
false.empty? => true

These are not quite as intuitive as NilClass and Fixnum but I agree they
would be nice to have as well.

How is 0 empty? 0 is a number representing nothing; it's not empty.

How is nil empty? It's nothing, thus it can't be empty.

A string is a container of symbols/character. A string containing no
symbols/characters is empty.

An array or a hashtable is a container of elements/items. An array or a
hashtable containing no elements/items is empty.

Stop equating [] and nil. Ruby is thankfully not PHP,
nikolai

 

[Austin Ziegler]

But please please use a different name than "empty?", maybe "nothing?"
or "something?" or whatever else.

I think it was a joke, but why not #vapid? -- it came from the spawning thread.

-austin

 

[Pit Capitain]

I don't have actual code, but imagine looping through records returned
with financial data, and you want to print out a "-" if the field is
missing -or- zero. The whole "this field doesn't have any meaningful
information that contributes to the sum of the column" spreadsheet thing.

I would support an RCR with this proposal, under just about any method
name
And I agree, boolean types need the same method as well.

When dealing with financial data, you often have to calculate the product of a
couple of values: v1 * v2 * v3 * ... Here, the number, that "doesn't have any
meaningful information that contributes to the PRODUCT of the column", is 1. I
think you can find many examples where the number 0 is special, but you can also
find examples where another number is special.

Regards,
Pit

 

[Kaspar Schiess]

(In response to by
Gavin Kistner)

To be clear - the proposal is NOT to make Ruby act like one of the many
other languages where "", 0 and friends are treated as non-truth values
in boolean expressions. The proposal is simply to add an additional
method to all that allows a programmer to treat them the same in the
few cases where that is desirable.

I can't see why this method should be added to all of Ruby.. it seems to
apply to a special case you need to handle. You know, it is perfectly ok to
change stdlib just for your project... this is what Ruby is about.

I feel very at home with the distinction between empty and nil that is made
currently. In the case of financial data that may have empty cells I would
propose to add a small class layer between that has an empty? method.. thus
solving the problem in an app specific way and not changing the language.

kaspar

 

[Austin Ziegler]

I can't see why this method should be added to all of Ruby.. it seems to
apply to a special case you need to handle. You know, it is perfectly ok to
change stdlib just for your project... this is what Ruby is about.

I feel very at home with the distinction between empty and nil that is made
currently. In the case of financial data that may have empty cells I would
propose to add a small class layer between that has an empty? method.. thus
solving the problem in an app specific way and not changing the language.

This, or something like it, would be useful for the case where I have to do:

foo if bar.nil? or bar.empty?
foo(bar) if bar and not bar.empty?

It's not common, but it is common enough. I want to sometimes write it as:

foo if bar.empty?

...because for the purposes of what I'm doing (I think that this is in
Text::Format), +nil+ is as good as empty.

-austin

 

[Jon A. Lambert]

But please please use a different name than "empty?", maybe "nothing?"
or "something?" or whatever else.

How about "piningforcplusplus?" ;-)

J. Lambert

 

[Michael Neumann]

Michael Neumann, 22/2/2005 11:25:


Binary logic, 0 is false, 1 is true.

In fact, those are actual symbols and not numbers!

Regards,

Michael