Quite true, but do you not intend it to be viewed as "private" ala Java/C++ etc? In which case, the name may actually help to "enforce" your intentions even though the reality is actually different.

No I don't really want it to be viewed as the same as "private" in Java, C++ or whatever. I want it to be viewed as a solution to the sort of problem that is solved by "private" in those languages :-)

Since most Perl coders are used to using my and our to solve namespace issues with variables I think those would be more familiar terms.

The "private" concept in C++ conflates two separate issues:

• Preventing access to a method
• Describing the public interface of a class

I like being able to tease those different functions apart - it can sometimes be useful. For example I've seen C++ coders jump through some evil hoops to test their private methods (e.g. #define private public when compiling in the test framework - ewww! :-)

That said, the length is the main issue for me with using PRIVATE::. It's just too much typing.

Do I understand you correctly? You would have My:: namespace be like private and Our:: namespace be like protected? Or at least close to it, not exactly mapping to the concepts of Java or C++, but instead maybe more the spirit of the concepts (with a little bit of perl mixed in of course). Or am I reading into what you are saying too much? Because I kind of like that, it would be pretty easy for most perl programmers to understand as well.

quick aside:
I know Bjarne himself questions the idea of protected, but I have always thought it wasn't that bad, as long as it was in capable hands.

-stvn

Do I understand you correctly? You would have My:: namespace be like private and Our:: namespace be like protected

No :-)

My:: and Our:: were two alternate names for the same code. On reflection I decided that My:: was probably a poor choice since my is all about scoping lexical variables, while our is about scoping the name of package variables which, from a certain somewhat skewed perspective, is what I'm doing in the code.

Calling the functionality "private" or "protected" is potentially confusing since it doesn't do all the things that "private" and "protected" do. All it does is allow you to conveniently name a package for implementation methods so you can avoid having them interfere with your classes published interface.