You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A piece of code because nobody will understand this title:
moduleFoomoduleBarclass ::ObjectBarendendend
This works fine in MRI, where it uses the Foo::Bar constant. In Natalie, it tries to look up ::Bar and fails.
This structure is used in the Nesting fixture in spec/core/module, which causes all the module specs in the nightly test to fail (we'd also need to implement Module.nesting, but we could just use a stub method).
Look up the exact rules for this, what happens when there is a toplevel Bar module as well? This must be documented somewhere.
The text was updated successfully, but these errors were encountered:
I keep pondering this ... it bothers me. We do most of our namespace resolution stuff using the self and walking up the hierarchy of owner chains. But now, with this example, we cannot store Bar as an owner of ::Object, so we would need another clue to look for Bar.
Maybe we could pass an additional argument into ModuleObject::eval_body that is the self at time of definition. 🤔
A piece of code because nobody will understand this title:
This works fine in MRI, where it uses the
Foo::Bar
constant. In Natalie, it tries to look up::Bar
and fails.This structure is used in the
Nesting
fixture inspec/core/module
, which causes all the module specs in the nightly test to fail (we'd also need to implementModule.nesting
, but we could just use a stub method).Look up the exact rules for this, what happens when there is a toplevel
Bar
module as well? This must be documented somewhere.The text was updated successfully, but these errors were encountered: