Hi --

On Wed, 13 Aug 2003, Christoph R. wrote:

> Nathaniel Talbott wrote:
> ....
> > In many cases this form of nesting will create more typing for me than the
> > normal form of nesting! OTOH, I haven't ever had trouble with too much
> > namespace exposure except with top-level classes (like Queue) that cause
> > confusion when I forget to require something and they magically get used
> > instead of my classes without an (immediate) error. But this new form
> > doesn't solve that problem, so I don't see any benefit in how it behaves.
>
> If this does not benefit you just don't use the new feature.  Remember the
> protracted trouble with the scoping rules of Ruby's class variables (it took
> Matz a fairly long time to get things right).  Ruby's scoping are already
> complicated enough (especially in combination with eval scope).

(I'd still like to see an example of a case where benefit was
conferred :-)  But anyway.)

> The feature you are requesting run IMHO squarely against the current
> scoping rules and might push them over the edge (of being too
> complicated) ...

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? :-]

That alleviates my initial concern, which was that A::B::C was
introducing a whole new set of scoping rules along with the new
semantics.  I admit I still raise an eyebrow at the fact that it
follows "Answer 2", but at least it's a matter of degree rather than
kind.


David

-- 
David Alan Black
home: dblack / superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav