From: Nicholas Van Weerdenburg <vanweerd@...>
Date: 2004-12-08T00:40:15+09:00
Subject: Re: Freezing Variable Assignment

On Tue, 7 Dec 2004 13:44:09 +0900, Austin Ziegler <halostatue@gmail.com> wrote:
> On Tue, 7 Dec 2004 12:07:32 +0900, itsme213 <itsme213@hotmail.com>
> 
> 
> wrote:
> >> Eric points to variable.c, which implements the policy
> >> annunciated by itsme. And David correctly points out that the
> >> simple view of only looking at the instance variables does not
> >> paint the whole picture (e.g. freezing arrays).
> > I was talking about the pure object model part of Ruby. In such a
> > pure object model, a[1] and a[2] are instance variables (some
> > Smalltalk descriptions calls these 'indexed instance variables' as
> > opposed to 'named instance variables'). How something is optimized
> > in C is a different matter.
> 
> Ruby isn't Smalltalk.
> 
> In a Hash, foo['bar'] and foo['baz'] are not instance variables of
> the Hash. They are indexed items to the Hash, for certain, but they
> aren't instance variables in the least.
> 
> Frankly, I think your view of freezing is one that is not one that
> is useful in considering Ruby at all.
> 
> I don't think that freezing bindings is at all useful, and before I
> could even think of supporting something this drastic, I'd need to
> see use cases that couldn't be worked around in other ways.
> 
> > In any case, consider my postings as a point of view; it is a
> > clean and potentially useful one. The part about local variables
> > was not central to me; I was just looking for a bit more
> > uniformity in treatment of all variable bindings, even temporary
> > (local) ones. It makes things like dynamic binding more uniform to
> > implement.
> 
> I don't see any uniformity in freezing bindings.
> 
> 
> 
> -austin
> --
> Austin Ziegler * halostatue@gmail.com
>                * Alternate: austin@halostatue.ca
> 
> 

I think immutability is usually a good thing from a design point of
view, so I can see a general need to have more freezing options. When
trying to extend old, bad Java code, I do some minor refactoring- 1.
kill singletons, 2. make primary business objects immutable, and 3.
add good logging (poor man's design-by-contract/testing). This makes
the code understandable enough that some more aggressive refactoring
can be done in the absense of a test suite, and well as enable some
component level testing to be added, since it's now easier to seperate
some of the concerns in the code (gui for application logic in a swing
application, for instance). The point being the essential importance
of immutability and being be able to control it from a contractual
perspective.

And is there anyway to may attributes private so that subclasses can't
see them? IIRC, this is  possible feature of Rite. This would remove
some of the need, since immutability is enforced by invisibility.

BTW- Is freezing bindings simply a delayed constant? Or is there more to it?

Also, is there anything such as a deep freeze of an  object graph? I'm
guessing not, since that would something hard to generalize easily (I
think of all the Java serializatoin performance problems where it
turned out that the data  was pulling the application code along with
it).

Thanks,
Nick