From: Robert Klemme <bob.news@...>
Date: 2003-07-15T21:16:22+09:00
Subject: Re: Booleans


"George Marrows" <george.marrows@ps.ge.com> schrieb im Newsbeitrag
news:5e44d1a4.0307150201.7b1a6f08@posting.google.com...
> > While I also kind-of like the idea of a "to_b" method that can
determine if a
> > class is logically false, I see it causing lots of problems.  If that
were
> > possible, someone might take advantage of Ruby's flexibility to make
0.to_b
> > be false for their program.  This could lead to some real difficulty
in
> > understanding or running other people's code.
>
> You can already override parts of Ruby to cause plenty of odd
> behaviour:
>
> class Fixnum
> def + (y)
> 1
> end
> end
>
> puts "2 + 2 = #{2 + 2}"

That's true, but why should we add another option to shoot ourselves in
the foot?  I regard the to_b thing more serious than the changed operator
+ that you present: logical values always have to do with the way an
algorithm executes, while a different return value for + is still a number
and will only have minor impacts in most cases.  Especially think of
someone changing 0.to_b to return false and then using a module of someone
else that relied on 0 being true...

> I think Matz has commented on this topic before and said that the
> reason that only nil and false are logically false is for performance.
> The test for an object being nil or false is a very quick. If logical
> tests instead had to call .to_b then that'd be an extra message send
> on every if, and, or, when, ...

That's a serious reason, too.

Kind regards

    robert