From: "fxn (Xavier Noria)" <noreply@...>
Date: 2022-06-15T20:47:16+00:00
Subject: [ruby-core:108939] [Ruby master Bug#18832] Suspicious superclass mismatch

Issue #18832 has been updated by fxn (Xavier Noria).


There is something weird here somewhere.

In general, Ruby does not check the ancestors as far as I can tell. Take the same situation with non-empty nesting:

```ruby
module M
  class C
  end
end

module N
  include M

  class C < String
  end
end
```

That one does not raise, and `M::C` and `N::C` are different class objects.

This property is what allows you to be anywhere defining a class or module and be sure you are creating regardless of what the ancestors have (think about a chain you don't control like inheriting from `ActiveRecord::Base`.

As you know, the `class` and `module` keyword have their own constant lookup (to decide whether to create or reopen), and they look only in the first element of the nesting without checking its ancestor chain.

Why isn't the top-level acting the same way?

----------------------------------------
Bug #18832: Suspicious superclass mismatch
https://bugs.ruby-lang.org/issues/18832#change-98027

* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
The following code:

```ruby
module M
  class C
  end
end

include M

p Object.const_defined?(:C, false)

class C < String # (1)
end
```

prints `false`, as expected, but then raises `superclass mismatch for class C (TypeError)` at (1).

I believe this is a bug, because `Object` itself does not have a `C` constant, so (1) should just work, and the superclasse of `M::C` should be irrelevant.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>