From: pjb@... (Pascal J. Bourguignon)
Date: 2009-01-14T23:14:08+09:00
Subject: Re: Why do true and false have separate classes

Jason Roelofs <jameskilton@gmail.com> writes:

> On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com> wrote:
>> This has puzzled me a bit. I googled and came up with responses like --
>> in any case we use respond_to? for duck typing.
>>
>> I am writing a program in which some classes behave differently
>> depending on the data in various columns. Typically, this means
>> displaying and editing of cells. So true and false are boolean and are
>> displayed and edited as checkboxes.
>>
>> Having 2 separate classes really complicated things since i don't want
>> to define 2 separate renderers and editors for true and false.
>>
>> Just wondered what the thought behind this was?
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>>
>
> It's only the core philosophy of Ruby: You have objects send messages
> to those objects.
> If there weren't a TrueClass and FalseClass, what else would true and false be?

You could have a Boolean class with a truth value attribute.  But then
you couldn't implement ifTrue: and ifFalse: without circularity.

But even if we kept TrueClass and FalseClass, it would be better to have a common generalization:

(class Boolean 
  # empty
end)

(class TrueClass < Boolean
  # ...
end)

(class FalseClass < Boolean
  # ...
end)


So now the OP would be able to define methods at the level of the Boolean class only.
Instead he will have to define his methods at the level of the Object class.

-- 
__Pascal Bourguignon__