From: itsme213 <itsme213@...>
Date: 2004-12-11T04:06:33+09:00
Subject: Re: Freezing Variable Assignment


"Austin Ziegler" <halostatue@gmail.com> wrote
> What you're describing isn't Ruby, and tries to combine things
> for some ivory tower intellectual wankery

Hmmm. I see no need to get abrasive.

> There is no reason to iterate over an object's instance variables as
> a standard feature of the language.

A quick scan of the Ruby distribution yielded 40 uses of
'instance_variables'. Anything that smacks of reflective programming works
on the underlying object model, which includes access to and iteration over
things like all instance variables, all methods. Of course you know this, so
I may have misunderstood what you meant.

> It is a conceptual *mistake* to
> consider instance variables equivalent to the contents of a Hash or
> Array.

You are welcome to keep this view, and if it ends up being 'the Ruby way'
that's fine too. There is a decent history of work that finds if helpful to
think that all state in a pure object model is held in the slots of objects,
defined by something akin to
    Object # each_slot { | slot_index ,  slot_value | ... }

This is true at the meta-level, normal object level, and regardless of how
different slots might be implemented and accessed.

> An object has state. Whether that state is comprised of multiple
> instance variables, other internal state (e.g., Hash or Array
> collections), or both is ultimately irrelevant. If I do the
> following:
>
>     require 'transaction/simple'
>     a = %w(a b c d e f g)
>     a.extend(Transaction::Simple)
>     a.start_transaction
>
> The object referred to by 'a' has both internal state (the array
> values, e.g., self[0..-1]) and several instance variables added by
> Transaction::Simple. What is the state of the object? Both the
> internal state and the instance variables.

Sure. And if you are comfortable with requiring even further concepts of
'internal state', 'array values', etc. that's fine. I prefer the underlying
object model to say that the state of 'a' is comprised of a bunch of indexed
slots and their values.
    a.each_slot { | slot_index, value | puts slot_index, value }
would give something like
    0 a
    1 b
    2 c
    ....
    6 g
    @a  x1
    @b  x2
    @c x3

> > String.superclass #=> Object
> > String.instance_variables #=> []
>
> And I'm telling you that what you're doing is a fruitless exercise
> for some ideal of purity that *is not Ruby*. A String has state. It
> may *also* have instance variables (see Transaction::Simple) that
> contribute to its state.
> But whether implemented in Ruby, C, or
> assembly, it seems highly unlikely that anything will ever be done
> to expose the internal state implementation of String, when String
> is a fundamental object.

I was talking about the instance variables of String, not _a_ string. So my
question was: if you claim (Ruby's) instance variables, Hash, and Array
serve to explain all object state in Ruby, than please explain how String
knows that its superclass = Object, when String has no instance variables?
(I could ask this of any class X < Object.)

What I outlined requires no new magic here at all, and I'll bet it is the
way most Ruby-ists think of this particular example anyway. Every object has
some predefined *slot* which refers to its class. And this is true
regardless of whether that slot is available as an "@x" instance variable, a
special -99 integer index, a :_my_class hash key, via the Object#superclass
method, or only through C-code.

> And I think that it would be a waste of time, effort, and clarity.
> This would do nothing more than muddle Ruby's object model for
> people who aren't you.

Perhaps, perhaps not. It is hardly intended to dramatically change Ruby,
just to put a simpler and more uniform explanation (and possibly reflective
access methods) around object state.

I suspect this sub-thread is past its useful life :-)

Thanks!