Immediate values

[Florian Gross]

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:

variables are names for Objects. In Ruby's implementation Objects are
represented by VALUEs.

No instance variables ... unless created by Ruby code would be better.

They're not saved in the Object struct, however. They're stored externally.

How are floats and bignums represented?

Pointers to RFloat (klass, flags, value as double) and RBignum (klass,
flags, sign, length, pointer to digits). Whenever you create a new Float
or Bignum you get a new Object.

false, true, and nil are objects _referred to_ by 0, 2, 4, 6. Same reason as
above.

I have no idea what distinction you are trying to make there.

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.

Presumably the symbols themselves (or their corresponding strings) are
allocated somewhere within, or mapped from, the address block with that
0...7bit mask?

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.

 

[Tim Sutherland]

Hi, Ruth. So, when someone on the list uses uppercase VALUE, they are
refering to an object's symbol table id. The symbol table being the
global dictionary that pairs up a unique id with pointers to the actual
objects. VALUE is a C typedef.

[...]

There is no such global dictionary, all the information is encoded in the
VALUE.

See http://www.rubygarden.org/ruby?GCAndExtensions:

Ruby objects are represented by VALUE in the Ruby C API. This is a typedef
for unsigned long. The value 0 is used for false and 4 is used for nil.
Otherwise, if the two least significant bits are 00 it is a pointer to a
structure on the heap which represents the Ruby object. (i.e. if "value &
0x03 == 0.") Other values are immediate objects or special constants (small
integers, symbols, true). This works because the structures are always
quad-aligned in memory. (So the pointer is always a multiple of 4, i.e.
has lower bits 00.) Then for example FIX2INT converts a Fixnum to a C int
by right-shifting the VALUE.

 

[Florian Gross]

I used "value stored in variable" because you said:
'VALUEs are pointers to ...'
'they are identified directly by the pointer's destination'

But VALUE != value. VALUEs are in Ruby's internals what Objects are in Ruby.

variables are names for Objects.

That's ok too. But you will probably need to allow somewhere for inst-vars
and arr 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...). 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.

Of course there's also other things that refer to Objects. Arrays
contain Objects of course. Hashs map Objects to other Objects. Instance
variables are just a funky version of variables that are local to an Object.

I'm not sure where you're going with that whole Slot model. I think it
only applies for languages like Python and JavaScript where everything
is based on fields. (In JavaScript you can do obj["foo"] = function() {
.... } and then call it via obj.foo().)

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?

Yup, that's how I'd express it.

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.

VALUEs are pointers to Objects. But sometimes they mean something
different just on where they point. Ruby sees that the pointer has a
special format and can then skip dereferencing it because it already
knows what Object it stands for. This is the case with immediate
objects. They are stored directly in the VALUE. Tim Sutherland explained
this fairly well in his reply to _why's posting.

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?

There's no actual C struct behind the Object to back it up. Yet in Ruby
you won't even feel the difference, because it's just an Object. It acts
like an Object and all that. Because of how immediate values work in
current Ruby you will always get the same Fixnum for the above.

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.

Yes, I agree in that this whole discussion does not make much sense for
regular Ruby programmers. All you need to know is that everything is an
Object, that Ruby does provide a few built-in (mostly) immutable Objects
like Numerics and Symbols. (Immutable Objects are usually called value
objects in OOP terminology.) There's lots of ways that you or Objects
can refer to Objects, but you'd expect this anyway, and if you pass an
Object around you will not magically get a copy of it like in other
languages.

Ok. Is VALUE a struct or typedef defined in the C code?

typedef for long. This is why Ruby can only be compiled when
sizeof(long) == sizeof(void*).

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").

Actually for the conceptual object model there's just Symbols which are
immutable Objects. Everything else is pedantry.

 

[Ruth A. Kramer]

Ruth A. Kramer ([email protected]) wrote:
Hi, Ruth.

Just for the record, it's Randy. (I've been stuck using my wife's email
client on the fast.net address since my Linux mail server crashed.)

So, when someone on the list uses uppercase VALUE, they are
refering to an object's symbol table id. The symbol table being the
global dictionary that pairs up a unique id with pointers to the actual
objects. VALUE is a C typedef.

Thanks, that helps! (I'll probably just try to ignore VALUE when I see
it.)

Randy Kramer