From: itsme213 Date: 2005-01-11T08:21:26+09:00 Subject: Re: Immediate values "Florian Gross" wrote in > >>a is mapped to a VALUE. VALUEs are pointers to Ruby Object Structs. > >>Immediate objects are not represented by any Ruby Object Struct -- they > >>are identified directly by the pointer's destination. If Ruby sees such > >>a special pointer it does not need to resolve it. > > > > Fine. As long as we understand that the immediate object is not the value > > stored in variable a, but the _implicit_ object that resides at the > > destination pointed to by 'a'. This is just to have a consistent underlying > > explanation: > > I dislike this whole "stored at" model. It's too complex. Let's express > it this way: I used "value stored in variable" because you said: 'VALUEs are pointers to ...' 'they are identified directly by the pointer's destination' Everything I said works fine with 'the value of a variable' instead of 'value stored in variable'. > variables are names for Objects. That's ok too. But you will probably need to allow somewhere for inst-vars and arr[i] and hash[k] and ... to also be (names for? a different term here?) Objects. What would state in this object model be? a mapping of names to Objects? I think not ... each object would itself be a mapping of names to objects (via inst vars, arr[i]...). And state change and behavior of methods would in turn have to be explained consistent. A name and name-map explanation can be made to work consistently, and some formal object model have such a basis. But I have found that "slot that refers to an object", where slots can be named, indexed, or other special slots, is simpler for most (including learners); I'm now thinking that either my experience was an aberration or I am doing a dismal job of explaining it even to Ruby wizards like yourself. Let's go with "variables are names for Objects" x = y x and y are now names for the same object. Entirely independent of what class of object, or of internal implementation. Would you agree? > In Ruby's implementation Objects are > represented by VALUEs. But this throws me off. If Objects are represented by VALUEs, and VALUEs are pointers to Ruby Object Structs, then creating a new object means creating a new "pointer to Ruby Object Struct". Does x=Object.new create a new "pointer to Ruby Object Struct"? To which one does the new pointer point? Then does x=5 and y=5 create two pointers? Just trying to understand how your terminology would work. Could this not also lead to difficulty with your 'Immediate objects'. x = 5 # is x a name for an immediate object here? y = 5 # is y a name for an immediate object? the same immediate object? when did this immediate object come into existence? I really not trying to be dense, or obtuse, or academic :-( . just trying to get the bottom of it clear. > >>Because there is no actual Ruby Object Struct there are no flags (which > >>means you can't (un)taint them), no instance variables > > > > No instance variables ... unless created by Ruby code would be better. > > They're not saved in the Object struct, however. They're stored externally. So? I think we are interleaving and mixing a discussion of Ruby's internal implementation (which I appreciate your insights into, but which only a minority of Ruby programmers will need to understand) with an attempt to come up with a consistent explanation of the conceptual object model of Ruby e.g. for someone not used to a pure object model. > > Does object.id generally correspond to the way a reference to object is > > represented? What are the exceptions? > > I think .object_id just returns the destination of the VALUE pointer as > a Numeric. Don't trust me on this, though. Ok. Is VALUE a struct or typedef defined in the C code? > No, the remaining bits are used for storing the symbol ID which is based > on the symbol type (global, instance variable...), an id counter and > some bit shifting. Don't ask me why the symbol ID is generated that way. > I don't know. There's two tables, one for going from a String to a > symbol ID and one for the other way. Those are used for Symbol#inspect > and so on. Thanks for that. Back to the conceptual object model: If we now try to explain x = :foo x.inspect in terms of an implementation-independent object model, we would have to pretend that there were Symbol objects (just like any other), and that they had some instance variables (or 'names', if Object is a map from name to objects) for the string. In fact, we could easily even implement reflective methods like Symbol#instance_variable_get :@theString (in C) to poke around those tables and actually return a (frozen) string. We would not want to correspondingly implement #set because Symbols need that "instance variable" to be frozen (yes, I know it is not an inst-var at the C-level; and that Ruby does not have a notion of freezing an "instance variable"). Time to go kick my explanation skills into some semblance of respectability. And write some Ruby code.