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