Re: Re: __set() / __get() : limitation and/or unintentional behavoiur?

Matthew C. Kavanagh wrote:

Write your __set to not allow arrays to be set, and make arrays within your object private or objects with __set in their own right. You could in fact create a "CustomArray" or something and allow CustomArrays to be __set'd in your object, then control their contents with CustomArray->__set(). There's no problem here.

I don't even want to set arrays as overloaded properties and if I did I could come up with another hundred workarounds to avoid the problem - the ability to workaround a problem doesn't mean there is not a problem. I posed the question after trying to help someone with a question posed on php-generals ... and finding that the behaviour was actually rather strange and unintuitive (imho); Its still trivial to make php segfault when using __get()/__set() - I really don't care what I do with php, a segfault should never occur, at worst I get a nice FATAL ERROR telling what an idiot I have been... my tests with APC 3.0.10 show that despite the best efforts of mr. Lerdorf et al it is still segfaults intermittently when using [lots of?] objects (of varying complexity) that use __get()/__set()/__call()/etc - the last 24 hours lead me to suspect that not APC but the engine itself is the 'bad guy' ... unfortunately I don't have the C skills to test that theory.