Zero is true ... whoda thunk?

-> -----Original Message-----
-> From: David A. Black [mailto:dblack@wobblini.net]
-> Sent: Wednesday, May 19, 2004 7:40 AM
-> To: ruby-talk@ruby-lang.org
-> Subject: Re: Zero is true … whoda thunk?
->
-> The real world is highly overrated as a template for
-> programming languages and the concepts underlying them.

This statement would seem to argue for bending a language to utility, not
against utility. And using zero as a shortcut for false is certainly
utilitarian. If we are trying to create a language which is logically
consistent in all instances, then having a strict sense of bool-iness would
require that nothing is false but false and nothing is true but true. So
comparing “some string” to true should result in a no-method-available
error.

But (as is the current case) using any object to be true, we’ve are already
bending the language to utility. That’s certainly okay (I don’t have a dog
in this fight) but it’s inconsistent to do that but then say, “But we just
can’t use zero as false! It’s inelegant!” We’ve already begun to be
inelegant if the string “This string has nothing to do with boolean” can
evaluate to true.

Drew

→ -----Original Message-----
→ From: David A. Black [mailto:dblack@wobblini.net]
→ Sent: Wednesday, May 19, 2004 7:40 AM
→ To: ruby-talk@ruby-lang.org
→ Subject: Re: Zero is true … whoda thunk?

→ The real world is highly overrated as a template for
→ programming languages and the concepts underlying them.

This statement would seem to argue for bending a language to utility,
not
against utility. And using zero as a shortcut for false is certainly
utilitarian. If we are trying to create a language which is logically
consistent in all instances, then having a strict sense of bool-iness
would
require that nothing is false but false and nothing is true but true.
So
comparing “some string” to true should result in a no-method-available
error.

Ruby does not have booleans; There is true and false, but you will
notice that they are of type TrueClass and FalseClass; not Boolean.

But (as is the current case) using any object to be true, we’ve are
already
bending the language to utility. That’s certainly okay (I don’t have
a dog
in this fight) but it’s inconsistent to do that but then say, “But we
just
can’t use zero as false! It’s inelegant!” We’ve already begun to be
inelegant if the string “This string has nothing to do with boolean”
can
evaluate to true.

Testing an object for true/false is simply a test of existence of said
object; “This string has nothing to do with boolean” exists, so it is
considered true. Nonexistence of an object is represented by an object
of NilClass. FalseClass is a convenience class that let you pretend you
are working with boolean values in your code.

Many times on this list (and in RCRs) people have suggested changes in
thee way Ruby handles true and false values. Many times, I have seen
matz reply that ‘false’ is just a “typical” false value. I took that to
mean that “existence vs. nil” is the general case, whereas “true vs.
false” is the convenience case; just a shortcut.

Also:

method one

if milk_volume
puts “there is some milk”
end

method two

if milk_volume.nonzero?
puts “there is some milk”
end

method three

if milk_volume > 0
puts “there is some milk”
end

Which of these make the most sense? Which would you find easier to
explain to your mother? :slight_smile: Personally, I would choose method two, but
would fall back on method three if I needed it.

Also, it is interesting that calling #nonzero? on a number returns nil
if it was zero, or its value when nonzero.

cheers,
–Mark

···

On May 19, 2004, at 6:20 AM, Mills Thomas (app1tam) wrote: