Information

What's changed?

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?