Matz -- 

Thanks to you and Guy, I think I now understand what it's doing - we could
call it the 'surrounding class then inheritance hierarchy' rule.

.. but I'm afraid I'm still not clear on *why* this rule is used, in
particular how it helps to 'make scope resolution as static as possible'.
Could you provide an example? 

All I see at the moment is that the rule introduces a (to me) unintuitive
special case for singleton methods: in Mark's example, o is effectively a
subclass of A, so it seems strange it can't directly access its class vars.
(See the ongoing ruby-talk discussion about objects with singleton methods
still being examples of their 'original' class..)

Thanks again for taking the time to explain. I'll write this up on the wiki
when we're done.

-- George

> |class A
> |	@@x = :a
> |end
> |
> |class B
> |	@@x = :b	
> |	class C < A
> |		def meth
> |			@@x
> |		end
> |	end	
> |end
> |
> |p B::C.new.meth   # => :a   (ruby 1.8.0)
> 
> Class variables look up follows the inheritance hierarchy starting
> from the nearest class or module.  In this example, look up for @@x in
> meth starts from C (nearest class), then A.  The reason is to make
> scope resolution as static as possible.