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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
