Peter Hickman wrote:
> Not wanting to troll you here but is this really a problem?
>
> Adding complexity to the language to hide things but at the same time
> requiring a way to circumvent the protection will achieve very little
> for much work. Remember I could just read the source code and use them
> with const_get.

That's fine.  I'm not concerned with people getting at my constants if
they really want to.  As things stand now the private/protected
keywords are are merely advisory anyway.  But, they do have their uses.

> If you provide good documentation for your module and the programmers
> have no need to access these constants then they wont. I do all of my
> programming using the docs, as I would guess most of the rest of us do.
> We have better things to do with our time than to dig into your code, we
> have stuff to write.

The digging could end up happening on the outside, not the inside, and
that's what I'm trying to avoid.  Say you're in an irb session and you
want to see what constants are available for the File class.  Normally
this would just be a handful of values.  If you were to do 'require
"win32/file"', however, you'll end up with a bunch of function pointer
declarations showing up in the output that you almost certainly don't
care about.  It messes up class inspection.

> And then there is the ego thing. Do you honestly think that you know
> better than every programmer who will ever use your module? There could
> be a real need to get at those constants, you are not omnipotent so just
> document your api and warn the users that if they use anything outside
> of the documented api then on their head be it.

Do you object to the existence of private/protected then?  You could
say the same thing for methods.  As I said, private is advisory only,
but it does have its uses.  For example, code coverage automation tools
could be configured to ignore private methods (which is what I'm
guessing most of them do by default).

> There is a theory about government that as time passes people will think
> that they should pass some laws or something just to prove their own
> vitality. There seems to come a point in with languages these days that
> people feel that they need to add feature just to show the language is
> alive.

I'm not sure how this makes Ruby more complicated. This adds very
little mental overhead and I think it would have very little impact on
existing code, since the majority of Ruby code that I've seen sticks
the public stuff at the top, and private/protected stuff at the bottom.

> Again I am not trolling you but I don't see this adding something to
> Ruby that is missing.

And that's what public discussion is for.  It's just an idea.  If Matz
and/or the majority of folks reading this message think it's stupid (or
too difficult to implement), then it will be rejected.  Otherwise, it
will be accepted.

Regards,

Dan