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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to