Posted by rick on 04/03/07 11:14

On 3 Apr, 01:17, Schraalhans Keukenmeester <bitbuc...@invalid.spam>
wrote:
>
> If keeping the variable shielded from client code is most important to
> you in this particular case, consider leaving them public, write a
> custom __get() and __set() accessors and catch attempts at meddling with
> $priv there. Not completely 'as it should' but it does the job.

What is most important to me is writing a class which can be inherited
by any class in my project - regardless of the type of access levels
of it's properties.

> Or define the (protected) variable in the parent class instead and
> access it through parent::$priv.

Then the parent class is no longer generic.

> I know protected vars in the parent class ARE visible to its children,
> but I haven't got a clue whether this also goes the other way around.

Protected variables in the child are visible to and settable by the
parent - it is only the private variables in the child which cause a
problem in this case.
Interestingly, the private variables in the child ARE visible to the
parent - as the Push() function detailed above does successfully save
the serialized details of the child into it's own 'Save' variable.
The problem is only that the Pop function cannot then set the private
variable of the child class.
Surely this behaviour is inconsistent - either the parent can access
private child properties or it can't ?

If anyone can let me know how to write this generic push/pop
functionality that can be inherited by ANY class in my system, please
let me know. This would also be useful for other functionality - i.e.
object caching [having a base caching class that can be inherited by
ANY class to allow the class to fully handle it's own caching
automatically].

[Back to original message]