From: Austin Ziegler <halostatue@...>
Date: 2004-11-12T06:15:09+09:00
Subject: Re: true? & false?

On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
> On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:
>> respectively. Thus, self == true and TrueClass === self (note the
>> inversion of parameters on the call to #===) are the same test.
>> You can more efficiently write what you want as:
>> 
>> class Object
>>   def true?
>>     false
>>   end
>> 
>>   def false?
>>     false
>>   end
>> end
> You might noticed from my previous posting, the reason to I want
> to have #true? and #false?

No, I didn't. Not anything convincing, at any rate. It seemed to
boil down to "I don't think that a == b is sufficiently OO", which
is certainly not a good reason, IMO. Why do you not like "a ==
true"?

> Example:
> a = true
> b = false
> 
> using my 'class Object'
> a.true? -> true
> b.false? -> true
> 
> using your 'class Object'
> a.true? -> false
> b.false? -> false
> which are wrong according to my proposed #true? and #false?

Not if you actually did what I said, which was *NOT* just adding
#true? and #false? to Object. Look again; it does what you want and
it does it cleaner than your == test.

>>> so.. again for the above examples: puts "a is true in boolean
>>> context" if a puts "a is really a *true*" if a.true?
>> Why is this better than "if a == true"
> I think, its a personal taste.

That rather goes against (IMO) sensible program design, especially
if you're going to work with others.

> I like "a.nil?" more than "a == nil"
> same way, I like a.true? than a == true

> "We live in a free world"

Yes, we do. I don't think, however, that the Ruby world needs #true?
and #false?

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca