From: Austin Ziegler <halostatue@...>
Date: 2004-12-07T13:44:09+09:00
Subject: Re: Freezing Variable Assignment

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