Bug #11055
closedautoload resets private_constant
Description
Is this behavior intentional?
Suppose the following file:
$ cat a/b.rb
class A; B = 1; end
This causes NameError
.
$ ruby -I. -e 'class A;autoload :B, "a/b.rb"; private_constant :B; end' -e 'p A::B'
-e:2:in `<main>': private constant A::B referenced (NameError)
But after it got loaded, A::B
becomes public.
$ ruby -I. -e 'class A;autoload :B, "a/b.rb"; private_constant :B; B; end' -e 'p A::B'
1
Files
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- File const-visibility-before-autoload-11055.patch const-visibility-before-autoload-11055.patch added
I doubt dropping the existing constant visibility information is intentional behavior. You can work around the current behavior by resetting private_constant
/deprecate_constant
inside the autoloaded file, but that leads to duplication.
Attached is a patch that will copy the constant visibility information across the autoload.
Updated by matz (Yukihiro Matsumoto) about 5 years ago
I agree with fixing this. Nobu will investigate the patch and consider the issue detail.
Matz.
Updated by jeremyevans (Jeremy Evans) about 5 years ago
- Status changed from Assigned to Closed
Applied in changeset git|47c97e1e843159c3c4d57f8c5e22daea57c3ffe1.
Do not lose existing constant visibility when autoloading
This copies the private/deprecate constant visibility across the
autoload. It still is backwards compatible with setting the
private/deprecate constant visibility in the autoloaded file.
However, if you explicitly set public constant in the autoloaded
file, that will be reset after the autoload.
Fixes [Bug #11055]