Re: Immediate values

itsme213 wrote:

>>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'

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[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.

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.

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

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.

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

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.