Premace:

This RFC aims to resolve whether or not protected class members will be prefixed with an underscore, or prefixed with nothing.

Once a decision has been reached, the result will be added to the PEAR coding standards.

Private members will still be prefixed.

These standards will only apply to PHP5 classes. In PHP4, if it's not public it's private and thus prefixed.

Voting:

</php>

</php>

A vote of 0 will not be counted.

If the overall score at the end of the call-for-votes is positive, class members will not be prefixed. If negative, they will be prefixed.

Information:

What's changed?

PHP5 Introduces PPP - Private, Public and Protected.

What's protected and private?

Protected members can be accessed in classes extending the class they are declared in, where as private members can only be accessed by the class they belong to.

What did we use to do, and why?

In PHP4, both private and protected members were prefixed with an underscore. This was to ensure the user of the class knew what methods were available to them, and not to mess with anything else.

One of the key reasons for prefixed members is the visual expression of "Do not mess with this member, I may remove/rename it in the future". This is fine for private members, however will not follow for protected members when the class is extended by the user.

Is it possible to accidently ignore the declarations?

If a member is declared as protected (using the protected keyword), an E_FATAL error will be thrown if the member is used incorrectly.

PHP5 will also provide errors if a user attempts to redeclare a
protected var as private. However protected members may be declared public by child classes.

In this regard 'protected' is like public in terms of the obligations of
the library author. For example, if you want to keep your public API small, but allow extending classes to expose more functionality. Or, if you would prefer to access class properties directly rather than using setter methods, you can redeclare the properties public in a child class.

In these situations, public vars would be prefixed as "private".

Does prefixing enhance readability?

Some would argue yes, some would argue no. Most large classes consist almost completely of protected members, with the public members reserved for the API.
In this situation, does having almost everything underscored really enhance readability?

Is private the same as protected? No, definitly not. Then why should it be prefixed the same? Some argue this actually decreases readability and confuses private members.

Is protected the same as public? No, definitly not. The user can't use a protected member (unless they are extending the class). In this example, protected has a lot more in common private. Should the user be protected visually (as well as with the language construct) from using protected members?