From: Jeremy Kemper <jeremy@...>
Date: 2005-11-17T10:10:45+09:00
Subject: Re: Object#to_b

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 16, 2005, at 4:48 PM, Daniel Sheppard 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 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.
>
> 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.

In Active Record:

   class Foo < ActiveRecord::Base
     has_one :bar
   end

I want a simple test for presence of bar, so return nil from
Foo#bar if there is no associated object:

   if foo.bar
     # ...
   end

I also want to treat Foo#bar as a reflection of the association
so I can have meta-methods for querying the column type, creating
objects, performing scoped queries, etc:

   puts foo.bar.column_type
   foo.bar.create(:name => 'first bar')

This usage feels very expressive and is possible for one-to-many
and many-to-many associations because acting like an Array is not
a problem.  But for one-to-one associations, we must act like nil,
which is impossible due to RTEST doing direct object comparison.

to_b is one way to do it, but I think it is too disruptive.
I would prefer to define #nil? and have RTEST call it.

Best,
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDe9iQAQHALep9HFYRArk3AJ4/tPb3QTnptm5LGFL2+s9MJlO5BgCeOGZH
DHvBGN0h+pD/ReEtk9kcjLk=
=TB0L
-----END PGP SIGNATURE-----