Re: Re: cvs: php-src /ext/standard array.c

Hello Christian, Saturday, November 20, 2004, 11:47:01 AM, you wrote: > Marcus Boerger wrote: >> We don't do this for any other interface based 'magic' (iterators, array >> overloading). But if that's your only concern then i'll happily change > I think the keyword here is 'magic'. This introduces another mechanism > for overloaded behaviour. > Something can now > a) implement an SPL-Interface > b) have reserved functions like __get or __call > c) behave 'normally' > I don't think SPL should be rewritten to use the reserved function > approach as it would be dozens of __-functions and for a lot of the > interfaces to check/require not individual functions but a whole set of > functions. That's what interfaces are meant for IMHO. > While SPL has great benefits and allows some really cool things I have > three wishes: > 1. Clearly document which functions/language constructs are affected by > SPL. Might be done already but I couldn't find it easily, that'd be my > mistake then :-) > 2. Restrict it to this set of functions/constructs and resist the > temptation to add more and more magic. And a lot of users _will_ ask to > add this or that function. Alternatively it could be restricted to all > functions within one chapter of the documentation, e.g. > http://php.net/array but then all the functions would have to > work with SPL. > 3. "There can only be one" Don't introduce more magic interfaces > overloading language behaviour. Make the author of another extension > like that sacrifice at least an arm, a leg and his first-born child > before it is allowed :-) We already decided not to allow ArrayAccess implementations to work in array functions - i just saw count() as the thing that makes ArrayAccess usable. However apart from coun()/Countable in general SPL only makes engine features usefull. Since count()/sizeof() is a lnagugae or even compiler feature in ost other languages it should result in it being moved to the engine in PHP. best regards marcus