On Friday, October 4, 2002, at 07:39 PM, Michael Lazzaro wrote:
[SNIP] > Definition: "private": > > A "private" attribute is an attribute whose scope is restricted such > that > it may be accessed only within the class in which it has been > declared. > It is not available to subclasses, nor to code outside the class. > [But see an alternative possible definition, below] [SNIP] > Note that an alternate definition of "private" is often used, as > follows: > > A "private" attribute is an attribute whose scope is restricted such > that > it may be accessed only within the class in which it has been > declared, > OR WITHIN ANY CLASS THAT INHERITS FROM THAT CLASS. I'll agree with that. > > Many programmers in fact expect "private" attributes to work this way. > Some languages recognize all three definitions, calling the above > "protected" access. I'm not sure what languages you are referring to specifically, but if you are including JAVA in that list then you are incorrect because JAVA allows protected members to be accessed from within any class within the same package as well, wether it is a subclass or not. > > The notion of "public" attributes is controversial within the OO > world. In general, public attributes may be better implemented as > public accessor methods to an attribute that remains private. (It > typically depends on how the language in question uses "attributes", > and whether the language treats attributes and methods in a roughly > symmetric fashion.) It depends on how you want to encapsulate your implementation details. One of the weakest points of PERL5 is data encapsulation (IMHO). A respectable language should, at its core, enforce a simple, straight forward notion of scoping. So while languages may differ on the types of scoping they offer, the rules and implementations surrounding them should be concise and not open for interpretation. Encapsulation in "OO PERL5" provides a multitude of opportunity for people to go out and kill themselves, and anyone else using their code in grand array of variations. Each variation producing its own unique and ghastly crime scene photo op. You have at your disposal such ghastly choices of mayhem as: Encapsulation via closures Tie::SecureHash Encapsulation via scalars...one of my personal masochistic favorites Something as basic as scoping/encapsulation should not be something left up to the programmer to create an implementation of. Nor, should they have the ability to create their own version of it. I'm all for having 16 ways to approach a problem but not when it comes to fundamental language aspects. That degrades the robustness of the language. Two words, 'access modifiers'. :-) OK, so back to the original topic of this thread. I like Java's notion of things. Attributes and methods are "package private" by default. Which means they are only visible to package they are in (slightly more restrictive then protected). Java also offers the following access modifiers: private - no visibility outside of the class protected - classes in the package and subclasses inside or outside the package public - all classes -Noah
