I recently stumbled over reflecting private properties in PHP again. As you might know, this was not possible until now and if you tried this [code] PHP thanked it to you with this [error that is cannot access a non-public member].

He notes that, while the behaviour is correct, it still makes things like metaprogramming impossible. So, what's a developer to do? Patch it of course! Tobias and Derick Rethans persuaded two other developers (Derick and Marcus Borger) to include a patch that allows the Reflection API to see these private variables.

To make it work, you have to use the setAccessible method on the Reflection object to set which of the properties you want to be able to get at.

The question asked about accessing properties outside the class and/or defining them as protected/private to prevent it. Stefan's response was basically:

Many OO techniques are designed for situations where you will have more than one programmer involved, now or later. By declaring variables as protected or private, you are adding security to the code base by forcing the use of getter and setter methods where you can control how objects are used.

The usage of interceptors (__get()/__set()/__isset()/__call()) makes your API a lot more readable and comfortable, while maintaining the purpose behind getters and setters: Checking the correctness of values assigned to a property and wrapping around retrieval mechanisms for a property. I personally call the way of maintaining value-correctness for properties through interceptors virtual properties, which fits quite nice I think.

Tobias gives an example of what he means by these "virtual properties" with an illustration from something widely used on the eZ Components libraries - comparing one method of setting text to an object to another (just setting versus the wrappers).

Some times there are some ancillary methods to deal with unsetting, checking for existence, setting via an array, or dealing with references in PHP 4. They can really clutter up the definition of a class. That's not good.

[...] I think the idea is to make the class extensible. But PHP is really ok with just setting new properties on a class. So why not just do this?

He argues that getters and setters in a class are less useful than just setting the property yourself. Using the property name as part of the interface, though (like getting the $obj->foo value with $obj->getFoo) is stil clean enough to be useful.

As arrays are the only complex types that are passed by value (resources don't really count here) the solution to described problem is simple: use an object; either an instance of stdClass or ArrayObject will do well, depending if you want to use array index notation.

He includes two code examples, one just trying to overload it in a class with __get (yielding an error) and the other using the constructor to pass an ArrayObject out first, allowing for error-free assignment.

Continuing our PHP functions article, we move on to creating classes. Let me say right at the start that you can write perfectly effective and useful PHP code without creating classes or going into object oriented programming. Object oriented programming can be very powerful and PHP programmers are increasingly taking advantage of these capabilities, which have been greatly expanded since PHP4.

They start with the creation of a simple class - a human class with two $legs and two $arms. They show a simple display of this data and add another attribute to the class, one for hair color. They then capture the output they've been creating inside a function, report, and show how to execute it. Finally, they show how to use the special function that runs when the object is created - the constructor.