Hello Sterling, Friday, June 27, 2003, 4:11:39 PM, you wrote:
SH> On Fri, 2003-06-27 at 04:09, Marcus Börger wrote: >> Hello Andi, >> >> Friday, June 27, 2003, 9:53:50 AM, you wrote: >> >> AG> Hey, >> >> AG> In general I think the ideas behind SPL are interesting. However, my main >> AG> problem with the whole array and iterator overloading is that it's not >> AG> quite clear to me where this should have an effect. Will it only work in >> AG> foreach()? Is it supposed to work in array_sort() and all other internal >> AG> functions? Is it supposed to work with assignment of the array() construct >> AG> to an object? >> AG> You can see where I am heading... I don't have the answers and I think we >> AG> might end up in one big mess... >> >> I can't see where you're heading because the engine structure makes anything >> besides my intention to use array syntax with objects impossible. According to >> iterators it is the same. They are intended to be used inside foreach but >> there is noone forcing you to do, it would be quite enough to use them in a >> for loop. However using them in a for loop wouldn't be that efficient. Anyway >> the idea behind iterators is to be possible to consistent way to work with >> that commonly used pattern. And in the future i plan to implement more higher >> level classes which will make use of the spl interfaces. And by the use of >> typehints this will becoming a really nice thing i guess. >> >> AG> About the use of interfaces for implementing methods such as __call(). This >> AG> might be sexier but in many cases it won't improve performance (I think). >> AG> For example, __call() only gets called if the first function lookup failed. >> AG> Once that happens we just check if ce has a __call function ptr. Searching >> AG> the class tree for the Callable_Overload (or whatever you want to call it) >> AG> interface will not be as quick, or in the least not quicker. >> >> To the above i can only agree, it will most likely not improve speed at all. >> However sometimes there are other things besides speed. And then, lemme think, >> checking for an interface (1) is much faster then search for a function in a >> function table and then it will be absolutly exceptional having __call so my >> idea is to remove the __call pointer and use interfaces instead. The result >> will be a little speed decrease for a vaste minority of classes but less >> memory. >> SH> It certainly doesn't have to hurt speed. Any cache that was maintained SH> with the former implementation could be maintained with the current SH> implementation. You also don't have to traverse the class tree. I SH> think for builtin interfaces you can just use bitmask and check that. I don't see a reason to make it more compley....but if performance is everything then some bitmasks would help of course. Anyway inside foreach hook of SPL those things are used (did you get it from there?) -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
