Chris Pine
12/30/2005 9:10:00 PM
On 12/30/05, J. Ryan Sobol <ryansobol@gmail.com> wrote:
> Two Fixnums of
> the same value always represent the same object instance, so (for
> example) instance variables for the Fixnum with the value "one" are
> shared between all the "ones" is the system.
Makes sense so far. Then we get this:
> This makes it impossible
> to define a singleton method for just one of these."
What!? The implementation makes it impossible, not the fact that
every 1 in the system refers to the same object. The constant
"Object" refers to the same object (the Object class) every time I
write it; this certainly doesn't prevent one from writing singleton
methods for it.
I'm not sure what the original author of that was trying to say, but I
think the real answer is just that, for whatever implementation
reasons (most likely for the sake of optimization), immediate objects
can't have singleton methods.
Again, my guess is that the choice was make to store singleton methods
(or the pointer to the singleton class) in some "ruby object" struct
that immediate values don't have. But what I find surprising (going
all the way back to the beginning :) is that, given this, we can still
define instance variables. The reason for this must be that instance
variables are stored elsewhere (not in this "ruby object" struct, but
in some other data store). But this seems an odd choice. I would
have thought that both the klass pointer (as I think they call it) and
the instance variables are stored in that struct. Maybe GC had
something to do with this design... I can't say more without looking
at the source.
(Isn't this usually where Guy steps in with an email consisting of 4
words and the exact lines of the interpreter code? :)
Chris