Re: [CFV] how to mark protected items?

Lukas Smith wrote:

Heino H. Gehlsen wrote:

The underscores are in my opinion mere leftovers due to Zend1's lack of PPP. Now that we have a better alternative in Zend2, we should no longer require the underscores, and it should be up to the developer to determine if private or protected variables and methods should be preceded by an underscore.

In Zend1 and Zend2 we document how a property/method may be accessed via phpdoc comments. In Zend2 only code we can additionally put in a technical barrier that prevents misuse. This effectively means that if the user doesnt look at the documentation he is slapped with an error (unless the error is suppressed). Eitherway its the users job to follow the documentation and not be surprised when undocumented things go away (since we do require phpdoc comments the API is actually by definition fairly well documented - atleast the @access tags make this fairly clear). The underscore therefore was always sort of a hungarian notation to prevent people from stupidly not following the documentation. So to say the underscore just screams "hey I am not public!". So argueing that it its a Zend1 thing is incorrect. The question is if we think this hungarian style notation is what we want or not (especially since we dont do this for types - then again that wouldnt make much sense most of the time in a typeless language).

I agree with the sentiment completely. The underscore makes it clear what is private/protected and what is not, regardless of syntactic sugar and docs. An underscore means "make sure you know what you're doing." It also means that when looking into the code for a class it is readily apparent what is and what is not public. If I'm looking into the code for a package, underscores make it obvious that the variable is internal and I need to look internally for its structure and use. Given that, if a class has no public members, I would say that it doesn't *really* need the underscores. After all, the members are all internal. However, this would create a split between packages and the same confusion as now as to what is and is not internal. In addition, if the class had a public member in the future, everything would have to be changed (unlikely), causing a break in CS. I am firmly in favor of _. It's *one more* character that makes the code much more readable and understandable without having to always be looking at the docs. Personally, these kidns of small hints make reading, debugging, and writing code much more enjoyable. -- paperCrane <Justin Patrin>