Zero is true ... whoda thunk?

ruby-talk
1

I’d prefer to encode this as:

if got_milk? … end

where

def got_milk?
@milk_volume.zero?
end

vs.

if @milk_volume … end

If milk volume is what? It just doesn’t read well, it doesn’t express
intent… its just poor coding, really. I’d contend there’s more of a “geeky
kind of logic” in 0 meaning false.

David
http://homepages.ihug.com.au/~naseby/

···

-----Original Message-----
From: Michael Geary [mailto:Mike@DeleteThis.Geary.com]

Because in the real world, zero means false.

Suppose you have zero quarts of milk in your refrigerator. I
am visiting and
I ask:

Got milk?

What’s your answer, yes or no?

No, of course.

2

David Naseby wrote:

If milk volume is what? It just doesn’t read well, it doesn’t express
intent… its just poor coding, really. I’d contend there’s more of a “geeky
kind of logic” in 0 meaning false.

This “geeky kind of logic” comes from back in the bad old days when
everyone wrote in assembly language (or C, which has all the power and
flexibility of assembly language with all the portability of assembly
language…). In those days, you didn’t have bools, or floats, or
strings - all you had were ints and arrays of ints. So one represented a
false value as 0 and a true value as 1 (or nonzero).

Tim.

···

–
Tim Bates
tim@bates.id.au

3

This “geeky kind of logic” is a legacy that disrespects 0:

David Naseby wrote:

I’d contend there’s more of a “geeky
kind of logic” in 0 meaning false.

Tim Bates wrote:

This “geeky kind of logic” comes from back in the bad old days when
everyone wrote in assembly language (or C, which has all the power and
flexibility of assembly language with all the portability of assembly
language…). In those days, you didn’t have bools, or floats, or
strings - all you had were ints and arrays of ints. So one represented a
false value as 0 and a true value as 1 (or nonzero).

Equal rights for Numbers: 0 is a Number, too!

Sure, Numbers are Comparable. Sure, 0 might be less than some other Numbers,
but it’s greater than some Numbers, too.

No Number should be considered false. No Number deserves to be considered
false.

No Number has the negativity and emptiness that nil and false exude. All
Numbers are on if’s guest list[1].

Granted, in the past it’s true that 0 had no bits set. It took on the roles
of false and even nil even when the need was there.

Give it credit for that! Respect, too, that all Numbers, yes, even 0, have
an id now.

I dream of the day programmers esteem 0 as highly as mathematicians.

Respect all Numbers equally. Join the fight for equal rights for 0.

honk if 0

(Besides, it’s just a simpler rule – only false and nil are false)

[1] http://www.poignantguide.net/ruby/chapter-4.html#section2

4

Dave Burt wrote:

honk if 0

Print bumper stickers! Three words say you’re a ruby fan…

5

Not to beat a dead horse, but semantically Ruby’s mechanism makes sense
to me from a coding perspective.

Once nil exists and is well used by existing libraries, what cases exist
for if(0) or if (1) (after the expression evaluates)? Those cases in
other languages are usually for existence or non-existence or a
comparison that doesn’t have anything to do with existence or
non-existence (e.g. > 100).

Since we often test for non-existence or existence, it is worth looking
at letting existing objects automatically say “true” meaning “I exist”
and nil objects say “false”, meaning I don’t exist. We gain a nice
syntactic shortcut, but does it cost us clarity or meaning for other
syntactical use cases? I don’t think so- or at least I haven’t noticed
it. I guess if( 0 ) evaluating to true is a bit confusing due to C
conventions, but that is quickly overcome and the elegance gained is
nice. 3 things evaluate to a boolean- an objects existence, it’s
non-existence, or a boolean. The first two being nice shortcuts.

Logically, it makes sense to me. Can anyone think of ugly syntacical
repercussions from this point of view?

Dave Burt wrote:

···

This “geeky kind of logic” is a legacy that disrespects 0:

David Naseby wrote:

I’d contend there’s more of a “geeky
kind of logic” in 0 meaning false.

Tim Bates wrote:

This “geeky kind of logic” comes from back in the bad old days when
everyone wrote in assembly language (or C, which has all the power and
flexibility of assembly language with all the portability of assembly
language…). In those days, you didn’t have bools, or floats, or
strings - all you had were ints and arrays of ints. So one represented a
false value as 0 and a true value as 1 (or nonzero).

Equal rights for Numbers: 0 is a Number, too!

Sure, Numbers are Comparable. Sure, 0 might be less than some other Numbers,
but it’s greater than some Numbers, too.

No Number should be considered false. No Number deserves to be considered
false.

No Number has the negativity and emptiness that nil and false exude. All
Numbers are on if’s guest list[1].

Granted, in the past it’s true that 0 had no bits set. It took on the roles
of false and even nil even when the need was there.

Give it credit for that! Respect, too, that all Numbers, yes, even 0, have
an id now.

I dream of the day programmers esteem 0 as highly as mathematicians.

Respect all Numbers equally. Join the fight for equal rights for 0.

honk if 0

(Besides, it’s just a simpler rule – only false and nil are false)

[1] http://www.poignantguide.net/ruby/chapter-4.html#section2

6

“Nicholas Van Weerdenburg” nick@activehitconsulting.com wrote in message
news:40ABFE84.4090509@activehitconsulting.com…

… 3 things evaluate to a boolean- an objects existence, it’s
non-existence, or a boolean. The first two being nice shortcuts.

Maybe it’s the latter that’s the nice shortcut, an object’s existence or not
being primal: see [ruby-talk:100755].

What may be a useful addition to this situation (of legacy (eg libraries’)
treatment of 0 return values as false), I think, is a to_bool that is
analogous NOT to to_s, but to to_str:

  • it would not be implemented in base classes, and probably not in Integer
    or its relatives, either;
  • it would obviously be not be automatically called by conditionals
  • it could be added to an Integer subclass

I realise after these dot-points that this is not well-thought-out at all –
what core classes are enough like booleans to implement this method by
default?

There’s probably more merit in having wrappers of legacy libraries behave
more rubyishly by returning nil when appropriate. A return-code class? Now
I’m just babbling.

At least, adding a to_bool to a class or a select few classes seems to be
the rubyishest way to get this kind of behaviour if, for whatever reason,
you deem it necessary. Things shouldn’t have to quack true or false.