From: RichardOnRails Date: 2009-12-23T01:05:47+09:00 Subject: Re: Ruby's implementation of Fixnum-assignment On Dec 22, 9:40 am, Robert Klemme wrote: > 2009/12/22 Rick DeNatale > > > > > On Tue, Dec 22, 2009 at 3:24 AM, Robert Klemme > > wrote: > > > 2009/12/21 RichardOnRails : > > > >>> 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 endhttp://blog.rubybestpractices.com/ Hi Robert and Rick, Thanks for honoring me with responses to what you guys must view as drivel. And I accept the assertion that Ruby recognizes "a=1" as an assignment statement rather than an invoking a apparently mythical "=" operator. >> 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). [snip] > Agreed. I see your point. But I've got a "burr under my intellectual saddle." Both Robert and Matz responded a few weeks ago on a question I raised about implementing a Fixnum ++ operator in Ruby functionally equivalent to C's prefix_++ operator. I'm not lobbying for such a change; I merely suggested that it's possible. The response was such an operator would be functionally equivalent to "turning 1 into 2." But I see the following: a = 1 # ID = 3 a = 2 # ID = 5 b = 1 # ID = 1 b++ # implemented as b.++() which increments b's object's ID by 2 and checks for edge cases; I don't see such an implementation as disturbing any other object, at least none on my machine's hardware and software state. > "a=1" is an assignment meaning, it > takes whatever object reference the evaluation of the expression on > the right side yields and puts it into the storage location denoted by > "a". There is no method invoked, certainly no method on "a" which - > as I said - is no object but just a place in storage. But aside from copying (in this case) 1's ID, Ruby must first look up a's presence in the current scope's portion of the symbol table and if not present, insert it, or otherwise deal with the existing ID for the "a" entry: (i) if the ID is an actual address of data in some pool, decrement its reference count if positive; or (ii) do nothing for Fixnums, true, false and nil). Looking at at actual IDs used on my 1.8.6.x version of Ruby on my Windows XP machine, I see these two cases are easily disambiguated: (i) ID is an even number greater than 4, perhaps (to account for false, true, nil, which are 0,2, 4. respectively) and (ii) everything else. I wouldn't even have posted my ++ question if I could follow my way through Ruby's C or C++ implementation. But in about my last decade before retirement, I was the debugger/enhancer of several organization's apps, so I know daunting the hunt through C/C++ code is, especially an app as big as Ruby. But if you pointed me to Ruby's Finite State Machine (there's GOT to be one), I'd ... With respect to you both, as well as thanks, Richard