From: Robert Dober <robert.dober@...>
Date: 2006-10-07T04:34:10+09:00
Subject: Re: nil being empty

------=_Part_134234_4982308.1160163241080
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/6/06, Trans <transfire@gmail.com> wrote:
>
>
>
>
>   nil.to_a


That is funny, I gnored it, it almost  replaces the problem, because now I
would say nil.empty? is  always -  me who hate  dogmae -  unnecessary, as w=
e
have

objcet.to_a.empty?

probably full with pitfalls, I guess this discussion might be futile, comin=
g
from one extreme - which I understand -
"nil cannot be empty as blue cannot be prime" to the other extreme which I
lile in an irrational way "nil.empty? define it if you like it" and in
between we have *nil.to_a*

  nil.to_s
>
> The core issue is really the dangers of extensions. Let's work on
> mitigating those. If we can do that, then we woun't have to be so
> concerned with unconventional polymorphisms.


That might be so, but I find your statement that nil should not be an objec=
t
seems much more valuable.
Just another  idea to work on

Void.class =3D> Class
Void.instance_methods.empty? =3D> true
NilClass.superclass =3D> Void
NilClass < Object   =3D> false
and maybe most importantly
Void.new.object_id  =3D> 42
Void.new.object_id  =3D> 42, the *same* 42  as above

and maybe
interception of NoMethodError for Void in string interpolation, hiding the
ugly part and having the Object Modell cleaner.
Object should change name of course :(

Just my 0.02c (sic)

Cheers
Robert

> T.
>
>
>


--=20
Deux choses sont infinies : l'univers et la b=EAtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

------=_Part_134234_4982308.1160163241080--