Hi --

On Tue, 7 Dec 2004, Jim Weirich wrote:

> > On 06 Dec 2004, at 14:12, itsme213 wrote:
> > > I respecfully but heartily disagree. Ruby freezes objects by freezing
> > > their instance variables. The latter is the fundamental operation.
> 
> On Monday 06 December 2004 07:47 pm, Eric Hodel wrote:
> > variable.c disagrees with you:
> 
> You guys are talking past each other ...
> 
> Itsme213: "Ruby freezes objects by freezing their instance variables"
> 
> Weirich Translation: When a Ruby object is frozen, the binding of its 
> instances variable names to values are made unchangeable (i.e. frozen).

David's previous statement on this: "One of the consequences of
[calling a.freeze] (though not the only consequence) is that a's
instance variables bindings are frozen." :-)

> 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).
> 
> But as far as classes implemented in Ruby (as opposed to classes implemented 
> in C), the viewpoint is pretty right on.

But that, in turn, is because Kernel#freeze freezes an object's state,
and state for non-builtins is generally (always?) a matter of instance
variables.  That's why I disagree with itsme213 that instance
variables are a good model for how to treat local variables.  (Not
that that matters, really; if it's a good idea to be able to freeze
local variable bindings [I'm not convinced it is], it doesn't have to
depend on analogy with Kernel#freeze.) 

One could perhaps reason that a Binding "has" local variables, in
somewhat the same way that an object "has" instance variables, and
that there should be some way to freeze those bindings too (i.e., the
bindings in a Binding).  The cases are not exactly parallel, though,
since a Binding can also have instance variables....  But it might be
an alternative way to approach it.  


David

-- 
David A. Black
dblack / wobblini.net