Superfluous Object:: in module name

[fxn]

Hi! I am replacing TracePoint with Module#const_added in Zeitwerk, and noticed the new test suite does not pass on TruffleRuby (this work is still not released).

The root cause is this:

class Module
  def const_added(cname)
    puts const_get(cname).name
  end
end

module M
end

That prints "Object::M", instead of "M".

I suspect it is related to internal callback logic specifically, because M.name is "M" later.

Version is

% ruby -v
truffleruby 24.1.0, like ruby 3.2.4, Oracle GraalVM JVM [arm64-darwin20]

/cc @byroot

[fxn]

Hey! Just so that you know :), I just published Zeitwerk 2.7 with that change. Due to this issue, Zeitwerk 2.7 does not work with TruffleRuby right now.

[eregon]

Could you point me to something that breaks?

irb(main):001:0> module M;end
=> nil
irb(main):002:0> Object.const_get("Object::M")
=> M

works for example, so while this is still a bug in TruffleRuby, Object::M is a valid constant path to reference M.

[eregon]

I think it would be nice to workaround this in Zeitwerk if possible, so that the latest TruffleRuby release is not broken.
If it's just a test failing no big deal but if it means Rails doesn't boot on TruffleRuby 24.1 due to this then it's a big deal.

[byroot]

"Object::M is a valid constant path to reference M." yeah, the problem is Zeitwerk keep the expected name in a Hash and need to look it up.

This can be worked around for sure, but it's a pretty hot loop, so should be done with care (or scoped under if RUBY_ENGINE == "truffleruby".

[byroot]

f it means Rails doesn't boot on TruffleRuby 24.1 due to this then it's a big deal.

People can just require "zeitwerk", "< 2.7" for now. So might not be worth shipping a workaround.

[eregon]

Could you point me to the code doing that? Maybe the key could be the module itself instead of strings?

People can just require "zeitwerk", "< 2.7" for now. So might not be worth shipping a workaround.

I suppose the error won't be clear so it's still a very poor user experience.

I just tried rails new railsapp --minimal, that uses zeitwerk (2.7.0) but both be rake test and bin/rails s seem to work fine.

[byroot]

Could you point me to the code doing that?

https://github.com/fxn/zeitwerk/blob/83277e0ff17728b07d99c1f8720332379b084456/lib/zeitwerk/core_ext/module.rb#L5

Maybe the key could be the module itself instead of strings?

No, the whole point is that this is registered before the module is loaded.

[fxn]

I just tried rails new railsapp --minimal, that uses zeitwerk (2.7.0) but both be rake test and bin/rails s seem to work fine.

Because the error only shows up with namespaces defined in files. Their child constants won't be found.

Maybe the key could be the module itself instead of strings?

There are projects where classes/modules are not hashable, learned that the hard way time ago.

[eregon]

No, the whole point is that this is registered before the module is loaded.

The constant already exists by the time const_added is called.

There are projects where classes/modules are not hashable, learned that the hard way time ago.

How is that possible? All Module instances have #hash via Kernel#hash. And if it's incorrectly overridden then one could use a {}.compare_by_identity Hash

[fxn]

How is that possible? All Module instances have #hash via Kernel#hash. And if it's incorrectly overridden then one could use a {}.compare_by_identity Hash

They had hash overridden to mean something else, and had a different signature (a debatable practice, yes).

In any case, this is a hot code path and the implementation was chosen among several options to be the most performant one. I'd need nested hashes to do this (because the key is a pair (mod, cname) conceptually).

I don't plan to revisit this implementation any time soon, unless I find something even more performant and backwards compatible.

[fxn]

@eregon, can you help me understand this thread?

TruffleRuby has a bug. I report it in advance. The reaction I would expect would be "thanks, we'll ship a fix as soon as possible". But I am feeling instead kind of a push back, and a proposal that consists on investigating in which way TruffleRuby is incompatible and that I release a new version to workaround the fact that TruffleRuby won't ship a new version. Or that I change an implementation that is correct.

Please don't get me wrong, I am asking this with sincerity.

Then, I see this as marked to be released in March 2025 (!).

Why?