From: Robert Klemme <shortcutter@...>
Date: 2009-12-22T23:40:25+09:00
Subject: Re: Ruby's implementation of Fixnum-assignment

2009/12/22 Rick DeNatale <rick.denatale@gmail.com>
>
> On Tue, Dec 22, 2009 at 3:24 AM, Robert Klemme
> <shortcutter@googlemail.com> wrote:
> > 2009/12/21 RichardOnRails <RichardDummyMailbox58407@uscomputergurus.com>:
>
> >>> For optimization purposes some object references are special in that they actually *are* the object
> >>
> >> That sounds like you mean in the case of Fixnum “1”,  that the number
> >> 1 IS the ID as well as the value of the object.  But we can see “puts
> >> 1.object_id” => 3
> >
> > No, it means that in the case of Fixnum the _reference_ is the object.
>
> A very good way to express this I think.

Thank you!

> > There is probably also a technical reason for this formula which
> > likely has to do with the fact that other objects need ids as well and
> > calculation of them should be efficient but I believe it is more
> > important to understand the object - object reference dichotomy.
>
> These things are artifacts of the implementation of the language.  I
> believe that in MRI the object_id is just the reference value 'cast'
> to a FixNum (or maybe Integer). So for an immediate object it's a
> particular bit pattern interpreted as an integer, and for boxed
> objects it's the address of the object's state interpreted as an
> integer.
>
> But this doesn't need to be the case, in an implementation which used
> a different object model for, say GC, and which interposed an
> indirection, then boxed objects might have an object id field kept
> with the indirection, so that the object state could be moved without
> affecting the object_id.
>
> Other Ruby implementations like JRuby, Rubinius, Maglev ... might
> implement such stuff in a way similar to MRI, possible with subtle
> variations, or some might do it radically differently.

Absolutely.  Again, when in Ruby land it does not really matter how a
particular implementation does it as long as the contract stays
roughly the same (i.e. #object_id returns something integerish).

> > Actually, I believe all this reasoning about Fixnums being immediate
> > values is totally overdone.  From a Ruby programmer's perspective it
> > is completely irrelevant (if you put performance aside for the
> > moment).  It is sufficient to know that Ruby has variables which
> > contain object references and that evaluation of whatever expression
> > yields an object reference.  The programming model is as simple as
> > that.  Immediate values are really just an optimization under the hood
> > to speed up math and other common operations.  In Ruby land, you have
> > no chance to distinguish an immediate value from any other immutable
> > object - whatever methods you invoke (and there are quite a few for
> > Fixnum) the object simply does not change its state.  Granted, there
> > are a few things that do not work, for example defining a finalizer
> > for a Fixnum but even that raises an ordinary exception.
>
> Agreed, the only time it's really important is edge-cases, and when
> writing extensions.

When writing extensions we're leaving Ruby land and so, yes, chances
are that you better know how things work under the hood then.  Do you
have any particular edge cases in Ruby land in mind?  Off the top of
my head I cannot think of any.

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/