Hello Andi,
Monday, June 30, 2003, 8:10:30 AM, you wrote:
AG> At 07:43 AM 30/6/2003 +0200, Andi Gutmans wrote: >>Hey, >> >>In my opinion beta 1 should be labeled as a beta. The fact that we are >>fixing a few features doesn't mean it's alpha. I know what the definition >>of alpha is but in real life most beta's do end up having quite a few code >>changes before release. >>I agree that we should try and feature freeze as much as possible right >>now. I'd like to see PHP 5 out before the 6-9 month period Sterling >>mentioned. I think we can probably do it within about 4 months if we don't >>mess with the code too much and listen to the feedback of people who are >>starting to play around with it. >> >>In my opinion, half the stuff listed by Marcus should wait for PHP 5.1 >>(which can be released very quickly after PHP 5): >>- Include SPL (forach/array hooking) (although we can discuss it and >>re-evaluate this once we finalize what we want).
AG> After Sterling reminded me that I did say that this should be considered
AG> for PHP 5 I'll clarify what I meant. What I meant by re-evaluating is that
AG> if everything falls in properly we should re-evaluate the patch before PHP 5.
AG> Let's see another iteration of the spec with pretty names and then decide
AG> :) Also, how are the benchmarks? What is slowed down and by how much? (it
AG> might very well be worth it but I'd like to know more or less). Last but
AG> not least, are there any things which won't work with this such as foreach
AG> with references and other problems?
According to foreach hooking a) I couldn't make out any problem that isn't fixed right now b) When included into the engine the differences are 3 additional comparisons in FE_RESET (2 pointers, 1 integer) 1 additional check in FE_FETCH (integer) 2 additional checks and a complex fetch in (SWITCH_FREE) -> that should be near to zero impact. In the early stages when it wasn't that optimized it was already near unmeasurable. c) IT makes no sense letting me do more work in here. I really can't see what i can do more. Of the new oo things it is right now one of the best documented and tested. So others have to test and report :-)
Array hooking is somewhat different. The impact is higher and it isn't really optimized right now. That's why i made it optional. The question here is whether we want it or not. But again being integrated in the engine the overhead can be reduced to a level described in foreach hooking.
Can you please post a patch for the foreach() stuff (i.e. collection and iterator)?
I don't exactly remember what you mean by array hooking. Is that what Andrei wants or does it also include a user-land interface to overload?
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
