Object can be typecasted into [associative] array and the protected members have keys prefixed with chr[0].'*'.chr[0] [see @fardelian's comment here]. Using this undocummented feature you can write an "exposer":
function getProtectedValue[$obj, $name] {
$array = [array]$obj;
$prefix = chr[0].'*'.chr[0];
return $array[$prefix.$name];
}
Alternatively, you can parse the value from serialized string, where [it seems] protected members have the same prefix.
This works in PHP 5.2 without the overhead of ReflectionClass. However, there are reasons why some property is protected and hidden from client code. The reading or writing can make the data inconsistent or the author provides some other way to expose it in effort to make the interface as lean as possible. When there are reasons to read the protected property directly, the then-correct approach was to implement __get[] magic method, so always check if there is any and see what it does. This counter intuitive lookup was finally solved in PHP 8.1 with readonly properties.
Since PHP 8.0, there also attributes metadata accessible by ReflectionClass, make sure to check them also before performing attempts to break into protected members. Attributes superseded "Annotations"1, so check them, too.
1: annotations are a very nasty surprise to client coders: they parse comments to add crazy fancy black-box useless confusing functionality, should not be used anymore, but they still exist
I realized something odd about accessing protected properties the other day. It’s possible in PHP to access protected properties from other objects, as long as they are from the same class, as illustrated here:
I always thought that protected strictly allows objects to access things from the current inheritence tree, but didn’t realize that this also extends to other instances of the same object.
This behavior works for properties and methods, and also when
they are defined as private.
The other day, I realized though that this even works for objects of other classes, as long as you are accessing members that are defined in a class that also appears in the accessing class’ ancestry.
Sounds a bit complicated, so here’s the example:
Interestingly, if the last example is modified so that the properties are not set in the constructors, but instead by overriding the property, this will break:
Because the third example throws an error, but the second does not, this makes me feel that I’ve simply stumbled upon an edge-case of the PHP engine, and that this feature is not by design. If it were designed as such, both should imho work.
After all if a certain behavior [in this case a property] works for an ancestor, the liskov substitution principle dictates it should also work for any sub-classes.
In addition, PHP normally only allows you to modify a property’s visibility to become more visible.
Still, I just ran into a case where the behavior of example #2 is super handy, but I’m not entirely sure if it’s a good idea to rely on this behavior, or to assume that this behavior is merely ‘undefined’ and could be altered without notice in a subsequent PHP version.
The PHP spec does not explictly disallow it though. This is the relevant text:
A member with protected visibility may be accessed only from within its own class and from classes derived from that class. source
Of course the PHP spec is likely not finished yet, and not sure if it’s vetted by the PHP team at all.
So I’m left not really knowing wether relying on this behavior is a good idea, but at the very least it’s immediately a good example of why having a correct and official PHP standard is a great idea.