From: Austin Ziegler <halostatue@...>
Date: 2005-11-17T10:22:35+09:00
Subject: Re: Object#to_b

On 11/16/05, Daniel Sheppard <daniels@pronto.com.au> wrote:
> The actual need for an Object#to_b is that there's no way to make your
> own custom object that will behave in a false/nil manner.

I don't know that this is a good or useful thing. I think that it would
decrease the overall clarity of Ruby code.

> I can't think of a usecase where I'd want to put extra information
> into a nil/false object instead of using exceptions, but maybe one of
> those people that keep asking about subclassing FalseClass and
> NilClass can explain their use-cases.

And I think that if they do, they'll be directed to different possible
solutions.

> Unless somebody can come up with a decent use-case, I'd say that we
> just change the if evaluations to also allow subclasses of FalseClass
> and NilClass (which will all be just singletons as they don't have
> new). Or change if to look at nil? to determine whether it's true or
> not.

Hm. No, I don't think that either is good. I would suggest that neither
FalseClass nor NilClass should meaningfully have subclasses and that if
should *not* look at #nil?. I don't think that there is a good case to be found
for this at all.

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