From: Nicholas Van Weerdenburg <vanweerd@...>
Date: 2004-12-11T13:00:39+09:00
Subject: Re: Freezing Variable Assignment

On Sat, 11 Dec 2004 12:33:51 +0900, David A. Black <dblack@wobblini.net> wrote:
> 
> 
> 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
> 
> 

I recall seeing "slots" used in Dylan. Is it used in any other
languages? Is it a common OO concept?

Nick