"Austin Ziegler" <halostatue / gmail.com>
> > Though it's hard to say "object x has states a, b" when you mean
> > "object x has instance variables a, b". Or "object x has states 1,
> > 2, 3" when you mean "object x has indexed variables (indices?) 1,
> > 2, 3".
> No, it isn't. It is very easy to say that "object x has a state
> of instance variables @a and @b" or "object x has a state of indexes
> 1, 2, and 3".

To each his own, since "easy" and "hard" are subjective :-)   To me:

"object x has slots @a, @b, 1, 2...5" (assuming "ivars" are unacceptable in
Ruby parlance)
   is better than
"object x has states @a, @b, 1, 2...5"
   which is better, simpler, and more uniform than
"object x has a state of instance variables @a, @b, or a state of indices 1,
2..5"

And I'd prefer (e.g. for generic object graph traversal)
          Object#each_slot  or Object#each_generalized_ivar
over    Object#each_state
over    Object#each_instance_variable, Array#each_index, Hash#each,
#each_key, #each_value
over    Object#each_whatever_an_extension_might_do_in_the_future

> Frankly, I don't think that a common term is useful or
> necessary. Array and Hash objects are fundamentals; everything else
> uses instance variables.

String.superclass #=> Object
String.instance_variables #=> []

I would find it hard to explain the above using your Hash, Array, and
instance variable. So is there some hidden instance variable ("slot") at
work here? What is special about it? Why is it hidden? Because it is
implemented in C? Like Array and Hash? But we'd then be making
implementation distinctions which I was trying to abstract away.

Most descriptions of an object model choose some term like "slot" or
"instance variable" or something else. I think this would be an improvement
on Ruby's (decent) description of its object model.

All of which is quite far off-topic from variable freezing :-)

Cheers !