From: Nathaniel Talbott <nathaniel@...>
Date: 2003-08-13T11:48:13+09:00
Subject: Re: Nested class/module namespace

dblack@superlink.net [mailto:dblack@superlink.net] wrote:

> In looking at the simplicity/complexity/consistency factors 
> in this, the question I keep coming back to is:
> 
>   when 'self' is a module or class, what is the visibility of
>   constants defined in enclosing modules and/or classes?
> 
> What's interesting is that even pre-1.8.0 there were at least 
> two answers to this, as illustrated here:
> 
>   # Answer 1 -- nested 'self' sees most recently defined constants
>   #             at higher levels:
> 
>   module M
>     X=1
>     class C
>       p self; p X                   # X is visible
>     end
>   end
> 
>   # Answer 2 -- nested/inner 'self' does not see constants at
>                 higher levels:
> 
>   M::C.class_eval { p self; p X }   # X is not visible
> 
>   __END__
> 
>   Output =>
>     M::C
>     1
>     M::C
>     con.rb:9: uninitialized constant X (NameError)
> 	    from con.rb:9:in `class_eval'
> 	    from con.rb:9:in `class_eval'
> 	    from con.rb:9
> 
> 
> So whichever way the new A::B::C syntax worked, it would not 
> be adding to or subtracting from the overall complexity of 
> scoping rules in Ruby.  It would simply be following one path 
> rather than the other.
> 
> [Aside to Nathaniel: does that help at all? :-]

It is good to know that it's not completely new... I guess the current
behavior still bugs me because the first example above seems _much_ more
common than the second example, and I'd expect this new construct to behave
like the more common construct, not the more obscure one. When I start
messing around with any of the eval's, I'm not surprised when I'm bitten by
weird rules, scoping or not. When I use a new construct that looks almost
identical to something I'm already familiar with, I don't expect to be
bitten by such things.

It violated my POLS, but then, I'm not matz ;-)


Nathaniel

<:((><