Hard to name this, but let me give an example.
foo.rb:
foo/version.rb
class Foo
VERSION = "1.2.3"
end
Ruby will set the superclass to whatever it loads first at runtime. That depends on the load order, which we don't want Rubydex to do. So we deviate from the runtime behaviour, picking < Bar even if we see foo/version.rb before foo.rb. This compromise makes makes sense in the multiple file case, to ignore the load order race.
But within a single file, this will always be wrong:
class Foo; end
class Foo < String; end # ❌ TypeError: superclass mismatch for `class Foo`
Notably, the inverse is fine:
class Foo < String; end
class Foo; end # No `< String`, but that's ok
Proposal
Add a diagnostic that checks for contradictory superclass definitions with each file.
Within the scope of a single file, we can eagerly assume that no superclass clause implies < Object, and then check that any further definition doesn't contradict that. Notably, this shouldn't change the interfile behaviour we havem where a missing superclass clause does not imply < Object.
Hard to name this, but let me give an example.
foo.rb:
foo/version.rb
Ruby will set the superclass to whatever it loads first at runtime. That depends on the load order, which we don't want Rubydex to do. So we deviate from the runtime behaviour, picking
< Bareven if we seefoo/version.rbbeforefoo.rb. This compromise makes makes sense in the multiple file case, to ignore the load order race.But within a single file, this will always be wrong:
Notably, the inverse is fine:
Proposal
Add a diagnostic that checks for contradictory superclass definitions with each file.
Within the scope of a single file, we can eagerly assume that no superclass clause implies
< Object, and then check that any further definition doesn't contradict that. Notably, this shouldn't change the interfile behaviour we havem where a missing superclass clause does not imply< Object.