From: Eric Mahurin <eric.mahurin@...>
Date: 2005-10-31T20:32:04+09:00
Subject: Re: determining whether an object is an immediate?

------=_Part_18986_12013326.1130758321505
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/31/05, Brian Mitchell <binary42@gmail.com> wrote:

> The clone test does not work. Reason? There are plenty of
> non-immediate objects that won't clone like Float and Bignum
> instances.


Didn't notice that. I wonder why they didn't make this work. If it were up
to me, I would make all immutable objects (including immediate objects)
return self for clone.

One test you could use is the singleton class:
>
> # Should raise a TypeError
> class << :immediate_object; end


I thought of that one previously too. The problem with this one is that for
non-immediates, it will create singleton/meta classes for them when I don't
need them. Maybe not that big a deal.

Of course immediate object could also be found missing from
> ObjectSpace, but I would imagine that test to be very slow.


Probably the best test for now, but slow.

May I ask why you need to know the immediacy of an object?
>

Performance. I don't really "need" to know - since this is an optimization.
I'm doing some code generation (parser generator). When I'm given an
immediate object instead of storing it in a variable and having the code us=
e
the variable, I want immediates to appear directly in the code (because
there is no object creation penalty and I know it is immutable). My
generated code doesn't reassign these variables (but it may modify the
objects) so this works.

Looking at the C code (ruby.h: SPECIAL_CONST_P), another option would be
this:

id =3D obj.__id__
(id&3).nonzero? || (id&~4).zero?

As long as ruby continues to encode immediates as it does now (can add
more), this should work.

------=_Part_18986_12013326.1130758321505--