Re: [PEPr] Comment on RFC::ProtectedMembers

Pepr wrote:

Klaus Guenther (http://pear.php.net/user/thesaur) has commented on the proposal for RFC::ProtectedMembers. Comment: The current standard states that any method or property prefixed with an underscore is for internal use. The proper understanding of such methods and properties is that they are protected, not private. The php4 "@access private" means that the marked methods/properties are private/protected. In other words, that they are non-public. (If the manual states it in any other terms, it is completely belied by usage.) It does not mean that they are private in the same sense as the term is used in php5 or other OO languages. If you want to see this demonstrated clearly, look at the HTML_Common base class. The prefixed properties and methods are used in extending classes. HTML_Common has no purpose in and of itself. However, I do see a definite merit in clearly marking a difference between private and protected items. This need is almost stronger than any need for marking protected items. So I'm wavering here between the positions :-)

This ignores the fact that the current standard exists because the langauge lacked any sort of enforcement. The visual cue was essential because there was nothing else besides API docs to help you along. This is no longer the case, so Alexey (or whoever said that) is correct: there is no precedent for this in PEAR because this is a new feature of the PHP language. The other langauges that I know of that support private & protected vars don't have any silly naming convention to indicate the priv/protected status of variables. "PHP5, you're access enforcement features are not good enough for us!" Hans