> > And that would be quite reasonable. But my build up to that is: what you
> > consider virtual object state is specific to your intent, and is derived
> > ultimately from slots, as follows:
>
> Well... but you're now using this concept of 'slots' uncritically in
> connection with Ruby objects, whereas this all began with my
> suggesting that the term wasn't really suited.

That's because it would be repetitive to say "instance variable, array
index, hash key or value reference, or some C-accessible data (like that
underlying Class#superclass)" in each place I used 'slot'. And state does
not work because state is some aggregation of instance variables or array
indices or hash keys or value references i.e. some aggregation of slots, and
this discussion needs to refer to _each element_ of that aggregation.

The fact that Ruby is very dynamic e.g. can add instance variables on the
fly, delegate, etc. does not change this. It just means we need to make some
distinctions, which we would need to be aware of in any case! e.g.
    We must know if x.freeze_all_instance_variables (or all array indices,
or hash ...) means
    (a) prohibit change to all currently defined ivars of x, or
    (b) prohibit change to all actual and potential ivars of x

> I don't necessarily consider the object to have a virtual state.

But I believe that _is_ what is intended by "freeze", and I think others
comments in this thread bear that out. I used the term 'virtual' just
because it could well extend beyond the immediate stored instance variables,
array indices ... etc. of the object. A Car implemented with 4 @wheel_i
instance variables would have shallower virtual state than one implemented
with a single @wheels[i] instance variable.

If I implemented MyHash below, I'd have to define #freeze to be consistent
with built-in Hash.
class MyHash
    attr_accessor :keys, :values
    def initialize; keys = []; values = []; end
end

> I'm still not buying "installs an @rng slot" as better than "defines
> an @rng instance variable" :-)

True. If that were the only context where slot was useful.

> I'm afraid I mean it more as a way of suggesting that the unifying
> notion of a 'slot' is not a very good fit for Ruby :-)

> It's an interesting discussion.  Actually, even though I didn't say
> anything and deleted it, I found the "custom freeze" idea particularly
> intriguing.

I thought "custom freeze" was the heart of what Nicolas started off with.
Assuming the default #freeze is always right for my objects is somewhat akin
(don't flame on the specific analogy, please) to assuming C++ default
constructors and assignment operators are right for my own complex objects:
the implementation might not align with my intended semantics for the
object. See my Car example.

> It reminds me obliquely of my desire for a "deep save" in
> ActiveRecord, though that's another story.... :-)

That's not surprising. Deep save, deep copy, freeze, equals, ... are a
family of methods based on the fact that the virtual state of an object (how
far out you go to save, copy, freeze, compare equality...) might well be
different than the (object references stored in) slots directly in the
object itself.

Cheers, and yes it's been an interesting and useful discussion for me too.