Forum: Ruby nil != []

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Alex P. (Guest)
on 2006-01-28 22:51
(Received via mailing list)
OK. Here's my second stupid question for today.

What's the rational behind having 0, [] and "" evaluate to true? ""
and [], I could kind of see. But 0, how on Gods earth can 0 true?

alex
Vince P. (Guest)
on 2006-01-28 22:57
(Received via mailing list)
I'm new to ruby but this makes sense to me.  Why should 0 == false?
It's a
valid FixNum.
Simon Kröger (Guest)
on 2006-01-28 23:06
(Received via mailing list)
Alex P. wrote:
> OK. Here's my second stupid question for today.
>
> What's the rational behind having 0, [] and "" evaluate to true? ""
> and [], I could kind of see. But 0, how on Gods earth can 0 true?
>
> alex
>
> --
> Alex P.
> http://flosspick.org - finding the right open source

how on earth can -1 be true?

No special reason, it's just that way. use zero? if you want to know if
it's zero. (What bugs you is the low level knowledge (or better an idea)
on how 0 and false would be represented in memory - Qnil is a 4 in ruby
:))

cheers

Simon

btw: i love pythons way in this case
Matthew S. (Guest)
on 2006-01-28 23:09
(Received via mailing list)
On Jan 28, 2006, at 20:51, Alex P. wrote:

> OK. Here's my second stupid question for today.
>
> What's the rational behind having 0, [] and "" evaluate to true? ""
> and [], I could kind of see. But 0, how on Gods earth can 0 true?

0 *the integer* is only false by convention, and it's a convention
confined to programming, originating (unless I'm mistaken) from
languages which didn't define specific 'true' and 'false' logcial
values separate from integer math.  0's used in some logical
notations as a symbol for 'false', but it's unlikely that anyone
familiar with formal logic will tell you those 0's are the same 0's
you get from "2 - 2".

There's no doubt that the convention's been made very useful, but
there's really no logical basis for equating any particular symbol to
true or false truth values over any other.

matthew smillie.
Jules J. (Guest)
on 2006-01-28 23:41
I think 0 is false because of the way it is represented in low-level
languages: a 0 (in binary). False is 0 too, and true is 1.

The Ruby definition of false/true is much simpler: everything except nil
or false is true.

Jules
Alex P. (Guest)
on 2006-01-28 23:42
(Received via mailing list)
On 1/28/06, Matthew S. <removed_email_address@domain.invalid> wrote:
> On Jan 28, 2006, at 20:51, Alex P. wrote:
>
> > OK. Here's my second stupid question for today.
> >
> > What's the rational behind having 0, [] and "" evaluate to true? ""
> > and [], I could kind of see. But 0, how on Gods earth can 0 true?
>
> 0 *the integer* is only false by convention,

Well I do understand that it's a convention. They same is true for a
lot of things. Like the positioning of gas and break pedals in cars.
It's just a convention. But when GM puts a new car in the market they
don't swap them. My question is why the constructors of Ruby did?
alex
MenTaLguY (Guest)
on 2006-01-29 00:00
(Received via mailing list)
On Sun, 2006-01-29 at 06:39 +0900, Alex P. wrote:
> Well I do understand that it's a convention. They same is true for a
> lot of things. Like the positioning of gas and break pedals in cars.
> It's just a convention. But when GM puts a new car in the market they
> don't swap them. My question is why the constructors of Ruby did?
> alex

Among other things, it makes things like ||= much more useful.

-mental
Sebastian Steinlechner (Guest)
on 2006-01-29 00:06
(Received via mailing list)
Alex P. wrote:
> Well I do understand that it's a convention. They same is true for a
> lot of things. Like the positioning of gas and break pedals in cars.
> It's just a convention. But when GM puts a new car in the market they
> don't swap them. My question is why the constructors of Ruby did?

Well... 0 evaluating to false is a convention used mainly in the C/C++
programming world. Many other languages that have been around for years
don't treat 0 as false. Pascal being one of them, IIRC. So Ruby is not
really breaking with a convention -- as there is none.

Sebastian
Matthew S. (Guest)
on 2006-01-29 00:33
(Received via mailing list)
>> 0 *the integer* is only false by convention,
>
> Well I do understand that it's a convention. They same is true for a
> lot of things. Like the positioning of gas and break pedals in cars.

Computer languages are not cars, nor are all conventions equal.  For
example, I'm unaware of any convention on what material the seats
should be covered in.  As far as 0 goes, there are languages out
there which don't even use numbers, let alone define particular
integers as 'true' or 'false'.

There are any number of reasons to favour either approach over the
other, so I couldn't possibly pick the exact reasons Ruby is the way
that it is, but there are a couple reasons to not let 0 equate to
false if you look at the very top of this page:

http://www.rubygarden.org/ruby?RubyIdioms

matthew smillie.
Stefan W. (Guest)
on 2006-01-29 00:49
(Received via mailing list)
Alex P. wrote:
> Well I do understand that it's a convention. They same is true for a
> lot of things. Like the positioning of gas and break pedals in cars.
> It's just a convention. But when GM puts a new car in the market they
> don't swap them. My question is why the constructors of Ruby did?
> alex

When you get used to it, it's quite handy. Some methods return integers,
and false values on failures. If 0 was false, you'd have to distinguish
between 0 and false/nil when checking for success.

Regards,
Stefan
Alex P. (Guest)
on 2006-01-29 12:09
(Received via mailing list)
On 1/28/06, Stefan W. <removed_email_address@domain.invalid> wrote:
> When you get used to it, it's quite handy. Some methods return integers,
> and false values on failures. If 0 was false, you'd have to distinguish
> between 0 and false/nil when checking for success.

yeah. that makes sense.

alex
Clint Checketts (Guest)
on 2006-01-29 20:53
(Received via mailing list)
On 1/29/06, Alex P. <removed_email_address@domain.invalid> wrote:
>
> On 1/28/06, Stefan W. <removed_email_address@domain.invalid> wrote:
> > When you get used to it, it's quite handy. Some methods return integers,
> > and false values on failures. If 0 was false, you'd have to distinguish
> > between 0 and false/nil when checking for success.
>

Dynamic typing in Ruby also aids the use of false = false and 0 = 0.

In Java I can't suddenly say that my variable contains a 'False' value.
I
would have to make my int = 0 and detect the rationale behind that
specific
integer. Dynamic typing solves this because myVariable = 5 and later it
can
equal 'false' when it really is false (rather than a
number that represents false)

-Clint
amrangaye (Guest)
on 2006-02-02 00:28
(Received via mailing list)
>When you get used to it, it's quite handy. Some methods return integers,
>and false values on failures. If 0 was false, you'd have to distinguish
>between 0 and false/nil when checking for success.

One example of this that tripped me up today is the regular expression
match operator (=~), which returns (0-based) the index of a match, or
nil otherwise. If 0 was false, you couldn't do:

if str =~ /^Hello/

.....
This topic is locked and can not be replied to.