Re: Name resolution in Ruby

Thanks for your response, Guy.

ts <[e-mail]> wrote in message news:<[e-mail]>...
> >>>>> "A" == Alan Stern <[e-mail]> writes:
> 
> A> 	First, the source is rather long and hard to understand.
> 
>  Well, if you really think this then you must look at the source of a P
>  language :-)

I believe you!

> 
> A> Instance variables are nearly as simple.  Every object contains a
> A> table of instance variable values, and an instance variable name is
> A> looked up in the table of the current object (i.e., the value of
> A> "self").
> 
>  instance variables are "private" variables

Quite so.

> 
> A> You would think that class variables would be equally simple to
> A> explain, but they're not. 
> 
>  class variables are "shared" variables

This is currently under discussion in a separate thread.  I think a
consensus is growing that class variables really ought to behave more
like instance variables of the class itself, with appropriate accessor
methods.

> 
> A> Local variables operate by way of bindings.
> 
>  local variables are resolved at compile time

That depends on how you look at it.  Since the code for a method is
only parsed once, if the parser resolved the local variables at
compile time then an occurrence of a variable like "i" would refer to
one fixed thing.  But when a method is called recursively, an
occurrence of "i" in the inner stack frame refers to an object
different from the one referred to by the same occurrence of "i" in
the outer stack frame.

> 
> A> 	[That the order of the lookups works as described can be
> A> demonstrated by the following sample code:
> 
>  a class is just an object like any other objects.

While largely true, that's not entirely correct.  Ordinary objects and
classes differ in the way their metaclasses are created.  For
instance, suppose that x is an ordinary object (not a class) and that
C is a class.  Then C always has a metaclass -- it is created at the
same time as C (I think) -- but x only has a metaclass if you create
one explicitly.  Also, if C is a subclass of B, then Meta-C is a
subclass of Meta-B.  This means that, although Meta-x's superclass is
x's original class, Meta-C's superclass is not C's original class but
instead is C's superclass's metaclass.

> 
> A> For a qualified constant name, like AClass::CONST or ::CONST, the
> A> search starts in AClass or the top-level class (however that gets set;
> A> the top-level class is altered during processing of a file by the
> A> Kernel#load command if the wrap parameter is set to true).
> 
>  Well be carefull with this, even with the wrapper you can retrieve old
>  constants like ::Array and modify the class if you want.

Yes.  Do you know if there is any way, within the wrapper, to access
the original top-level object and class?

> 
> A> The overall effect is that constants behave as though they really do
> A> have a static scope.
> 
>  This is the intented use, I think.
> 
> 
> 
> Guy Decoux

Alan Stern