Project

General

Profile

Feature #11547

remove top-level constant lookup

Added by gucki1 (Corin Langosch) about 2 years ago. Updated 21 days ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:<unknown>]

Description

If ruby cannot find a class in the specified scope it uses the top-level constant of the same name if it exists and emits a warning:

irb(main):006:0> class Auth; end
=> nil
irb(main):007:0> class Twitter; end
=> nil
irb(main):008:0> Twitter::Auth
(irb):8: warning: toplevel constant Auth referenced by Twitter::Auth
=> Auth

In some cases this is not playing nicely with rails autoloading as can be seen here: https://github.com/rails/rails/issues/6931. Many more issues like this exist.

Imo I don't see any reason why this fallback makes any sense. So I'd like to suggest to remove it completely or at least add an option to disable it.

Associated revisions

Revision 57244
Added by nobu (Nobuyoshi Nakada) 11 months ago

variable.c: top-level constant look-up

  • variable.c (rb_const_search): [EXPERIMENTAL] remove top-level constant look-up. [Feature #11547]

Revision 57245
Added by nobu (Nobuyoshi Nakada) 11 months ago

test for [Feature #11547]

History

#1 [ruby-core:71240] Updated by shugo (Shugo Maeda) about 2 years ago

  • Status changed from Open to Feedback

Corin Langosch wrote:

If ruby cannot find a class in the specified scope it uses the top-level constant of the same name if it exists and emits a warning:
(snip)
Imo I don't see any reason why this fallback makes any sense. So I'd like to suggest to remove it completely or at least add an option to disable it.

How should the following code behave?

class Foo
  X = 1
end

module Bar
  Y = 2
end

class Baz < Foo
  include Bar
end

p Baz::X
p Baz::Y

#2 [ruby-core:72041] Updated by gucki1 (Corin Langosch) almost 2 years ago

Hi Shugo. Just as it does now, it doesn't perform any magic (fallback to some other scope) and doesn't emit any warning. How is it related to my bug report/ feature request? Cheers, Corin.

#3 [ruby-core:72130] Updated by shugo (Shugo Maeda) almost 2 years ago

Corin Langosch wrote:

Hi Shugo. Just as it does now, it doesn't perform any magic (fallback to some other scope) and doesn't emit any warning. How is it related to my bug report/ feature request? Cheers, Corin.

In my example, Baz::X and Baz::Y refer to constants defined in ancestors of Baz.
In your example, Twitter::Auth also refers to a constant defined one of its ancestors, Object.

So, I'd like to clarify what behavior do you want in these cases.

Instead of changing the behavior of constant lookup, we may be able to introduce a variant of const_missing which is invoked when a constant is not directly defined in the target class.

#4 [ruby-core:73766] Updated by bronson (Scott Bronson) almost 2 years ago

Corin, I completely agree. Recently, Rails's nondeterministic autoload made it very hard for me to discover this problem. Without the insightful warning, I would have been sunk.

Shugo Maeda wrote:

Instead of changing the behavior of constant lookup, we may be able to introduce a variant of const_missing which is invoked when a constant is not directly defined in the target class.

Couldn't Ruby 3.0 just raise an error instead? Shugo, your example seems to demonstrate that Ruby is smart enough to realize when the behavior is intentional vs. when it's probably an accident.

I'd be happy to bang together a patch if the concept seems sound.

#5 [ruby-core:74131] Updated by shugo (Shugo Maeda) over 1 year ago

Scott Bronson wrote:

Corin, I completely agree. Recently, Rails's nondeterministic autoload made it very hard for me to discover this problem. Without the insightful warning, I would have been sunk.

Shugo Maeda wrote:

Instead of changing the behavior of constant lookup, we may be able to introduce a variant of const_missing which is invoked when a constant is not directly defined in the target class.

Couldn't Ruby 3.0 just raise an error instead? Shugo, your example seems to demonstrate that Ruby is smart enough to realize when the behavior is intentional vs. when it's probably an accident.

I'd be happy to bang together a patch if the concept seems sound.

The behavior change might be acceptable in Ruby 3.0 if Matz wants.
Experiments with real world applications such as Rails might help his decision.

#6 [ruby-core:74918] Updated by matz (Yukihiro Matsumoto) over 1 year ago

I am for this proposal, but also concern about code breakage. Let's try removing top-level constant look-up in 2.4dev and see how much code it breaks.

Matz.

#7 [ruby-core:78915] Updated by tisba (Sebastian Cohnen) 11 months ago

With 2.4 released and I wasn't able to find anything related to this issue in https://github.com/ruby/ruby/blob/v2_4_0/NEWS I guess it did not make it into 2.4.

I was wondering if there are any plans regarding working on this. In almost all projects I encounter this issue and it would be great if this could improve.

#8 [ruby-core:78926] Updated by nobu (Nobuyoshi Nakada) 11 months ago

Sorry, missed this feature.

#9 Updated by nobu (Nobuyoshi Nakada) 11 months ago

  • Status changed from Feedback to Closed

Applied in changeset r57244.


variable.c: top-level constant look-up

  • variable.c (rb_const_search): [EXPERIMENTAL] remove top-level constant look-up. [Feature #11547]

#10 [ruby-core:78928] Updated by bronson (Scott Bronson) 11 months ago

The fix is even simpler than what I was picturing: https://github.com/ruby/ruby/commit/44a2576f798b07139adde2d279e48fdbe71a0148

If it sticks, this will make a bunch of Rails autoload issues go away. Right on nobu, thanks!

#11 [ruby-core:78929] Updated by fxn (Xavier Noria) 11 months ago

In particular this one http://guides.rubyonrails.org/autoloading_and_reloading_constants.html#when-constants-aren-t-missed.

We'd love to base Rails autoloading on Kernel#autoload and have the exact same semantics, but that is not possible as of this writing (http://guides.rubyonrails.org/autoloading_and_reloading_constants.html#module-autoload-isn-t-involved). So, Rails does not attempt to emulate constant resolution at all (it does not have nesting information, it does not follow ancestor chains by design, etc.), you have to think autoloading as a feature with its own contract. You have to program against that contract.

A change like this one is welcome though. Thanks.

#12 [ruby-core:78945] Updated by zenspider (Ryan Davis) 11 months ago

I would honestly rather see it raise an exception instead of silently return nil. I'd rather KNOW my bug than hunt it.

#13 [ruby-core:78954] Updated by fxn (Xavier Noria) 11 months ago

Oh, didn't look at the patch. This means String::Hash returns nil?

#14 [ruby-core:78955] Updated by fxn (Xavier Noria) 11 months ago

Ah, no, https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/57244/entry/variable.c#L419 seems to say that Qundef is what the search function returns to indicate failure, raising in the caller.

#15 [ruby-core:83644] Updated by fxn (Xavier Noria) 21 days ago

I realized that Object does not halt the lookup, but it is rather just skipped. For example, constants in ancestors of Object are still accessible as qualified constants:

module Kernel
  X = 1
end

X         # top-level accessible constant
String::X # still accessible this way

Is that intentional?

Also available in: Atom PDF