Hi --

On Sat, 11 Dec 2004, itsme213 wrote:

> "David A. Black" <dblack / wobblini.net>
>
>>> Your rand() example is about (4).
>>> rand() has to mutate some stored state somewhere (i.e. some variable,
>>> instance, global, class, C-only, ... ). Your obj can reach and modify
> that
>>> stored state via rand(). I am guessing obj.rand[10] would affect the
> outcome
>>> of a subsequent obj2.rand[10] i.e. this random number state is cetainly
> not
>>> local stored state (1) in obj.
>>
>> I don't see how or where any state is stored.  Are you talking about
>> the behavior of the random number generator, and the fact that *it*
>> isn't in the same state after calling obj.[]?  If so, I definitely do
>> not consider that part of the state of obj itself.
>
> 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.  Of course we don't
have to reach accord on this, but I just have to point it out since my
response to quite a lot of this is along those lines :-)

> (a) obj has no local stored slots that reflect state of the rng (that it has
> no local stored slots at all is coincidental)
>
> (b) If you transitively walk all slots from obj, any subset of that space
> _could_ be what you consider virtual state of obj.

I don't necessarily consider the object to have a virtual state.  I
consider it to have the potential to have state (I could add instance
variable-based state to it dynamically), but as written, it doesn't.
I don't consider the random numbers to be virtual state -- maybe
something that masquerades as state, but that's different (at least I
would view it differently).  Virtual state, to me, might evoke state
that is actually held in a delegated object.

> (d) There is rng state somewhere, and rand() itself somehow accesses and
> manipulates that state. Where that state is, and whether or not you want to
> consider it part of the virtual state of obj is entirely specific to the
> desired semantics for your obj. It is reasonable for you to not consider the
> rng as part of obj state.
>
> On the other hand, I can also conceive of an implementation of rand() that
> installs an @rng slot on obj itself, points it at a new
> RandomNumberGenerator instance (with its own slots representing the state of
> that generator). And I can conceive of situations I would want obj#freeze to
> totally freeze the state of that RNG instance as well (or not).

I'm still not buying "installs an @rng slot" as better than "defines
an @rng instance variable" :-)  But in any case, I'm not sure I can
quite picture it, since rand is a method of Kernel.  Without explicit
assignment, I wouldn't want such a method changing the state of my
object.  The object's instance variables should be 100% its business.
(I know about instance_variable_[gs]et, but they're really considered
meta-programming-ish and therefore "allowed" to cross otherwise strict
boundaries.)

>> "Contains" in the sense that Array#[] shows you what's in the
>> collection, as does Hash#[].  [] doesn't always index a collection,
>> even in built-in classes, and certainly doesn't have to; but my point
>> was that my object acts as if it were a typical collection, using []
>> to get at elements.
>
> So would you use "contains" for anything a method might return? Or would you
> limit it to some subset of those things it's slots can get to, directly or
> indirectly? I think I read more into it than you meant.

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 :-)

> Sure, [] (or any accessor) can return any stored or derived value, from
> colletions or otherwise. Some of them may be part of what you choose to
> consider your object state, others not.

The great thing is, though, that it often doesn't matter -- 
especially with things like delegation, dynamic object extension,
etc., which you can just use without having to decide what their exact
status is with regard to the object's state.  I don't mean that you
shouldn't know what's going into your design, but sometimes
terminology just adds an extra layer without much gain.  In fact, the
term "state" itself is hardly able to keep up with the life of a Ruby
object (at least a very lively one :-)

Come to think of it... that's also my problem with "slot" -- it
strikes me as creating a set of constraints or expectations that Ruby
probably won't follow or match.  And in such a case, I consider Ruby
right and the terminology questionable (in the context of Ruby).

> Did that make it any better? Or worse? :-)

It's an interesting discussion.  Actually, even though I didn't say
anything and deleted it, I found the "custom freeze" idea particularly
intriguing.  It reminds me obliquely of my desire for a "deep save" in
ActiveRecord, though that's another story.... :-)


David

-- 
David A. Black
dblack / wobblini.net