# we can even refer private constant from its parent scope
module SomeModule
p PrivateClass #=> SomeModule::PrivateClass
end

=== Background ===

Traditionally, there is no way to prevent users from using your classes.
It is too easy for user to access any internal class (e.g., CGI::Html3,
Enumerator::Generator, Matrix::Scalar, URI::Util, etc).
We can only write a document to ask users not to use them.

RubySpec inspired me to propose this feature. RubySpec declares the
policy that no spec should be written for private method. Nevertheless,
there were some specs for internal classes, such as CGI::Html3 (FYI,
such specs are already deleted).
I thought this was because there is no way to explicitly declare that
the constants are "internal use only."

=== Proposal ===

Private constant is a scoped constant that can be referred only from
its parent scope. It can be used for declaring "the constant is
for internal use," like private method.

When users try to refer private constant, they can realize that they
are going to use non-guaranteed feature, because the constant cannot
be referred so easily. Even so, they can use such a feature with
self-responsibility, by explicitly opening its parent scope.

Since the default visibility is public, this feature does not break
any compatibility.

=== Current status ===

I first suggested this at .
Matz approved my proposal
Yugui has also approved , but said that it is needed
to discuss in ruby-core list before commit.

The patches are attached. make check and make test-rubyspec are all
passed.

1) Is it intentional that const_get :K, where :K is a private constant, raises a NameError? In the context of private methods, the reflection API only enforces visibility constraints if they have been explicitly requested (e.g. #methods c.f. #private_methods).

2) Should private constants be returned by #constants? They currently are, but #methods excludes private methods. That is, all methods returned by #methods may be objectified with #method, yet the same is not true for constants. Further, as there is no predicate for determining whether a constant is public or private, the programmer must resort to rescuing NameError when using #const_get. This represents an incompatibility in that existing code of the form K.constants.map{|c| K.const_get c}, where K contains one or more private constants, will now raise an exception.

3) Is it intended that, given the name of a private constant, #set_const makes it public?

No problem. Thank you always for your detailed spec review.
# Say, I wanna work on File.write...

1) Is it intentional that const_get :K, where :K is a private constant, raises a NameError?

No. I think #const_get' does not raise an exception for
private constants because#method' and `#send' does not
for private methods.

Matz, may I introduce a new method #public_const_get', like#public_send'?

2) Should private constants be returned by #constants?

I think no. I'm attaching a patch.

Matz, may I introduce two new methods, #public_constants'
and#private_constants'?

3) Is it intended that, given the name of a private constant, #set_const makes it public?

No. I'm attaching a patch.

NOTES:

Matz is now casting doubt on this feature ;-( because
we've not estimated the impact of this feature yet.
Though I thought that I certainly got matz's approval,
I might make a quick judgment.
We're discussing still now, but this feature may be
reverted.

Matz is now casting doubt on this feature ;-( because we've not estimated the impact of this feature yet.
Though I thought that I certainly got matz's approval, I might make a quick judgment. We're discussing
still now, but this feature may be reverted.

It would be a shame if it's reverted. There are a few rough edges, but nothing insurmountable. FWIW, I agree with your changes.
=end

Kazu committed a change of NEWS with ML ref, which closed this
ticket. I think that he did not intend to close this ticket.
That is, it is just accident. I'm reopening this ticket.

Yusuke, patches in the mail I'm replying are not applied

Yes, just because of my laziness. I will work on.

and we still need discuss about followings, right?

I think that what we needed is not discussion, but matz's final
approval.
The reason why this ticket stopped was because matz cancelled
his approval and opposed this feature at .
And, matz has finally re-approved it at .
So we can now move on.

Module#constants includes a private constant?

It should not. I will.

Module#const_get raises NameError for a private constant?

It should not. I will.

add Module#public_constants and Module#private_constants?

Plus, Module#public_const_get. But these may be need matz's
additional approval.

Matz, can I add these methods:

Module#public_constants, which returns an array that contains
only public constant names.

Module#private_constants, which returns an array that contatins
only private constant names.

Module#public_const_get, which returns a value assigned to the
constant if it is public, or raise a NameError if it is private.

Kazu committed a change of NEWS with ML ref, which closed this
ticket. I think that he did not intend to close this ticket.
That is, it is just accident. I'm reopening this ticket.

Yusuke, patches in the mail I'm replying are not applied

Yes, just because of my laziness. I will work on.

and we still need discuss about followings, right?

I think that what we needed is not discussion, but matz's final
approval.
The reason why this ticket stopped was because matz cancelled
his approval and opposed this feature at .
And, matz has finally re-approved it at .
So we can now move on.

Module#constants includes a private constant?

It should not. I will.

Module#const_get raises NameError for a private constant?

It should not. I will.

add Module#public_constants and Module#private_constants?

Plus, Module#public_const_get. But these may be need matz's
additional approval.

Matz, can I add these methods:

- Module#public_constants, which returns an array that contains
only public constant names.

- Module#private_constants, which returns an array that contatins
only private constant names.

- Module#public_const_get, which returns a value assigned to the
constant if it is public, or raise a NameError if it is private.

What was this deemed significant? I can't think of single reason why anyone would actually have to have a "private", as opposed to a "public", constant. Constants are CONSTANT so they aren't supposed to be changed after they are defined anyway --indeed normal channels of doing so will cause a warning. And constants aren't methods, so they aren't something you can call to effect object state. So what's the point? Why add all this new complexity for working with constants, e.g. #private_constants vs. #public_constants? I just see additional headache with nothing at all gained.

I can't think of single reason why anyone would actually have to have a
"private", as opposed to a "public", constant. Constants are CONSTANT so
they aren't supposed to be changed after they are defined anyway --indeed
normal channels of doing so will cause a warning. And constants aren't
methods, so they aren't something you can call to effect object state. So
what's the point?

You can have constants defined which are purely an implementation detail
that you don't want to be public-facing, because they aren't intended to be
relied upon or modified. Hiding private modules and classes aside, I can
see a benefit from hiding that information.

While these private classes might be an implementation detail in your design, what if someone comes along and wants to build off the work and thus needs to subclass one of these implementation detail classes?

I can understand the thought behind it. On the surface we clearly think of certain classes and modules in our projects being the public interface and others, the majority of them in fact, being implementation details. But codifying that, rather than just documenting it, is bound to be more frustrating than useful.

But codifying that, rather than just documenting it, is bound to be more
frustrating than useful.

Isn't that the point of trying to crack open an implementation detail to
rely on? It should be difficult if it's just a detail that can change at
any moment. It's not really different from having private methods. If you
really want to get at them, you still can.

Methods are different b/c they can effect state --they can be dangerous. If it wasn't for that, there would be little reason to have private methods either.

So, what does this "if you really want to get at them, you still can" look like?

As I think about the scenarios of use for this feature, I just don't see it bringing anything really helpful to the table. But I do see it annoying people when there programs break as a new version of some library decided all those "implementation details" should be private.