From: Eric Wong <normalperson@...>
Date: 2015-10-22T21:01:05+00:00
Subject: [ruby-core:71165] Re: id_table cannot work for const_tbl

�������� �������������� <funny.falcon@gmail.com> wrote:
> But, is "class path name resolution" specified somewhere?

I am not sure.  matz?

> In other words:
> perhaps it matters more to change tests instead of abandoning this idea.
> 
> "class path name resolution" affects only runtime generated classes
> (created by `MyClass = Class.new()`, and not `class MyClass`)
> (and WEBrick::HTTPStatus::Unauthorized is runtime generated).

I think it's not unreasonable to expect people rely on a particular
name of a class.

For instance, I have used string matching on class names to avoid
triggering an autoload.

> And it only may break code which relies on stringified class path name of
> such runtime-generated classes (which is very rare in practice).
> 
> This particular test can be fixed, if `const_set(err_name, err_class)` will
> force
> name resolution for `err_class` if its name not already resolved.

Maybe the following is enough for "const_set" method callers
(also in https://bugs.ruby-lang.org/issues/11614 )

--- a/object.c
+++ b/object.c
@@ -2185,6 +2185,14 @@ rb_mod_const_set(VALUE mod, VALUE name, VALUE value)
 {
     ID id = id_for_setter(name, const, "wrong constant name %"PRIsVALUE);
     rb_const_set(mod, id, value);
+
+    /*
+     * Resolve and cache class name immediately to resolve ambiguity
+     * and avoid order-dependency on const_tbl
+     */
+    if (RB_TYPE_P(value, T_MODULE) || RB_TYPE_P(value, T_CLASS)) {
+	rb_class_name(value);
+    }
     return value;
 }

All tests pass, at least...