[ruby-core:66284] [ruby-trunk - Bug #10488] Consistency of Module#const_defined? and constant lookup

Issue #10488 has been updated by Xavier Noria.


Regarding the first point, here `const_defined?` is consistent with `const_get`:

```ruby
X = 1
Module.new.const_get(:X) #=> 1
```

In general the constants API seems to be "closer" to the algorithm that resolves constant names than the one for constant paths.

However, if I got true from `const_defined?` I would expect to be able to access the constant in the next line so to speak. This is not guaranteed nowadays... in my view it would be more coherent to autoload.

----------------------------------------
Bug #10488: Consistency of Module#const_defined? and constant lookup
https://bugs.ruby-lang.org/issues/10488#change-49956

* Author: Benoit Daloze
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: current: 2.2.0
* ruby -v: ruby 2.2.0dev (2014-10-12 trunk 47890) [x86_64-darwin13]
* Backport: 
----------------------------------------
Currently, if for some module `mod` and constant `Const`,
`mod.const_defined?(:Const)` is true does not imply `mod::Const` is not an error.

This is inconsistent for at least the following cases:

* if mod is a Module but not a class, `const_defined?` will look in `Object` and its ancestors, but constant access (::) will not look in `Object` or above.

    ~~~ruby
    Enumerable.const_defined? :String
    Enumerable::String #=> NameError: uninitialized constant Enumerable::String

* if `Const` is private, `const_defined?` will return true while `mod::Const` will raise an error.

    ~~~ruby
    C = 42
    Object.private_constant :C
    String.const_defined? :C #=> true
    String::C #=> NameError: private constant String::C referenced

    # This works, but is due to the lexical scope lookup
    class String
      C #=> 42
    end

Is this intended?
Should it not mirror the behavior of `defined?(mod::Const)`?
Or the behavior of `method_defined?`




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