[#99868] [Ruby master Bug#17144] Tempfile.open { ... } does not unlink the file — eregontp@...
Issue #17144 has been reported by Eregon (Benoit Daloze).
15 messages
2020/09/03
[ruby-core:100027] [Ruby master Feature#17171] Why is the visibility of constants not affected by `private`?
From:
eregontp@...
Date:
2020-09-16 21:13:12 UTC
List:
ruby-core #100027
Issue #17171 has been updated by Eregon (Benoit Daloze).
mame (Yusuke Endoh) wrote in #note-3:
> I did not introduce `private_constant` with no receiver because I wanted to avoid a new module state (as I recall, matz now dislikes the module state), but I agree that it is redundant.
Interesting, is `private` implemented as state on the module? (but then would need to be thread-local when concurrently loading or so)
I always thought it's part of the state stored in the frame.
Regarding the issue, I agree it would be nice.
Maybe we can make an experiment and gather feedback from gems testing against ruby-head?
----------------------------------------
Feature #17171: Why is the visibility of constants not affected by `private`?
https://bugs.ruby-lang.org/issues/17171#change-87578
* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
----------------------------------------
```ruby
class Foo
def call_me
# ...
end
private
SOME_DATA = %i[...].freeze # is public, why not private?
def calc_stuff # is private, ok.
# ...
end
end
```ruby
It's probably a naive question, but why shouldn't `SOME_DATA`'s visibility be private?
When writing gems, more often than not the constants that I write are not meant for public consumption. I find it redundant (and tiresome) to explicitly write `private_constant :SOME_DATA`.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>