I believe the behavior was borrowed from Smalltalk (or was it Scheme?
one of them). Basically, "Everything is true except false". And nil.
You get to the point though - what makes zero so special that it would
warrant being false? I recall some vague memories from my Systems
Programming class about the professor saying that in C this is because
zero is an integers, and integers can be fit nicely into one
byte/word/unit thingee. A boolean doesn't, so it's a waste of
allocation space, which not so long ago was a quite precious resource.
An integer on the other hand could do all these other nifty things (be
added to, substracted from, etc.), and of all integers zero may as
well be the easiest one to represent bitwise. Now in Ruby the whole
aforementioned train of thought is irrelevant, because integers are
objects just like any other. Why should an existing object be false?
_It exists_. And as said first, "everything is true except false". Nil
is not "everything" (it's not even "something") so it it out of that
definition, and may thus be false.

On Wed, 19 May 2004 10:01:42 +0900, Chris Pine <cpine / hellotree.com> wrote:
> 
> On Wed, 19 May 2004 06:34:54 +0900, Mark Sparshatt wrote:
> > Richard Lionheart wrote:
> 
> <snip>
> 
> > One advantage of this is performance. Both NilClass and FalseClass
> > are singleton classes so checking whether an object is nil or false
> > is very easy, while allowing 0 to be false would require testing
> > the type and value of the object.
> 
> Actually, since 0 is an immediate value (like nil and false), it could be tested just as easily (as I understand it).  I would guess that the reason has more to do with elegance and simplicity.  In any case, aside from the "C does it that way" camp (whom we are obviously not catering to), why should 0 or any number be false?  (Why should "" or any string be false?  Why should [] or any array be false?)  Well, they aren't.
> 
> Chris
> 
>