Guy - thanks for the response - I certainly wasn't aware that it had been
removed in 1.8.1. However ev_const_get() etc still use information external
to RClass to work out class nesting. I was really wondering why this is
necessary - why can't the info be stored in RClass, so that it is intrinsic
to the class.

Anyway, I think I've found my answer, which is that the nesting structure is
not a property of the class, but rather a lexical property of the code. For
example:

class A
	X = :x
	class B
		Y = :y
	end

	class B; class C
		puts "=> using class B; class C"
		$c = self
		p self, Module.nesting, X
		p Y
	end; end

	class B::C
		puts "=> using class B::C"
		puts "self == class B; class C?  #{self == $c}"
		p self, Module.nesting, X
		p Y
	end
end

produces:

=> using class B; class C
A::B::C
[A::B::C, A::B, A]
:x
:y
=> using class B::C
self == class B; class C?  true
A::B::C
[A::B::C, A]
:x
const.rb:18: uninitialized constant A::B::C::Y (NameError)

In the second case, both the Module.nesting and the constant lookup skip the
A::B class. Obviously this kind of nesting can't be a property of the class
itself.

FWIW my understanding is that it works this way because Matz wanted to make
constant lookup as static/lexically-based as possible .. but I do find that
the result is counter-intuitive. My guess would have been that class B::C is
strictly short-hand for class B; class C, with the same constant lookups. I
know others have expressed the same feeling on ruby-talk. I'm pleased to see
that constant lookup will be revisited in Ruby 2.0!

-- George

>  cbase don't exist in the CVS version. 
> 
> svg% grep cbase ruby-1.8.0/env.h
>     VALUE cbase;
> svg% 
> 
> svg% grep cbase ruby-1.8.1/env.h
> svg% 
> 
> 
>  Perhaps best if you look the CVS source