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.
Okay, so what I understand from your answer is that Iterators should only be a PHP language feature (i.e. usable inside scripts and automatically supported by foreach). Any other internal functions or code which iterates over arrays will not use this. That's an OK definition as far as I'm concerned because I don't think the latter is feasible, I just want to make sure we're on the same page.
About array overloading I just want to make sure that $obj[1] is all you guys want.
I hope you don't expect the engine to translate $obj = array(1,2,3) into some kind of $obj[0] = 1; $obj[1] = 2; kind of thingy. If all you guys need is the former I think that makes sense.
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.
1) No need to traverse the class hierarchy.
I agree that there are things above speed. In any case, we could always make it an interface *and* for such important language level interfaces such as Callable_Overload support the ce->__call optimization.
I think that over all supporting the __get/__set/__call via an interface might have its advantages of cleanliness although it's a very subtle issue.
AG> A bit of a mess email but I hope I gave you guys some food for thought. AG> Please think about these issues carefully before replying.
Sure, i get what you maen. But maybe you should play a bit with the spl concepts already implemented. And by that get a feeling how sexy (sorry for borrowing the word) they really are. Maybe you could think about this.
I don't need to play with it. I've played enough with Java which does pretty much the same.
AG> In general, I don't think this should effect the release date of the beta.
Again, i can't see the hurry. I mean we have really good concepts here and two of the ideas are ready to rock. So the only thing we ask is whether we may include foreach/array overloading before beta 1.
The big hurry about beta 1 is that it has been lingering for too long and I think the only way to push PHP 5 is to finally get a beta out there. We can keep on compromising indefinitely because there'll always be that one last fix someone wants to do to the PHP 5 codebase and then we'd never get a beta out of the door.
Personally, I don't think this code needs to be in the tree for beta 1. From past beta experience we'll probably have another one within a month (because ppl will finally be using/debugging our code), so we can put that in beta 2.
So how do we get a formal spec for the changes (starting with nicer names, i.e. Iterator instead of spl_foreach)? :) It's probably best if you take Sterling's email and try and come to a final set of interfaces and a very very short explanation where relevant of what it'll do and then we can aye/nay each part.
Does that make sense? Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
