[ruby-core:31135] Re: Why is the inherited callback invoked at different times for static vs. dynamic subclasses?

Joel, that's right: it's the order of the calls that surprises me, not the class name (which is quite reasonable).

ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]

I found this ticket on Redmine filed by Jeremy Kemper, which seems to describe the same observation:

http://redmine.ruby-lang.org/issues/show/2793

The problem does not exist in 1.9.2 (ruby 1.9.2dev (2009-07-18 trunk 24186) [i386-darwin10.3.1]) in which get the following expected output

1.9.2:

A was inherited by B
Definition of B
A was inherited by #<Class:0x00000100866ab8>
Definition of #<Class:0x00000100866ab8>

1.8.7:

A was inherited by B
Definition of B
Definition of #<Class:0x100156070>
A was inherited by #<Class:0x100156070>


Regards,
Jacob

Den 08/07/2010 kl. 22.02 skrev Joel VanderWerf <[e-mail]>:

> Yukihiro Matsumoto wrote:
>> Hi,
>> In message "Re: [ruby-core:31130] Re: Why is the inherited callback invoked at different times for static vs. dynamic subclasses?"
>>   on Fri, 9 Jul 2010 02:52:48 +0900, Joel VanderWerf <[e-mail]> writes:
>> |1.8.7p299 seems to have the strangeness:
>> Because, there's no clue (for the interpreter) to get a name for the
>> value from Class.new(A), which is NOT yet assigned to C at the time of
>> evaluation.
> 
> I don't think the class name ("C" vs. "#<Class:0x7fa787968d00>") is the issue. It's the order in which #inherited is called, w.r.t. the class block.
>