On Fri, 2003-06-27 at 09:22, Andi Gutmans wrote:
> At 10:09 AM 27/6/2003 +0200, 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.
>
> 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.
Yep, this is also what I'm talking about.
> 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.
Yes. What I was talking about (as you'll see in my predefined interface
list), is simply something that makes array accesses look like property
accesses. The property name to get_property and set_property
>
> >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.
>
Yeah. My main purpose was for cleanliness, not performance. Its very
clear what you are doing when implement the interface. Further, you are
100% BC compliant, and you don't need those underscores before the
function names (unless of course you think they look better ;-)
> 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.
>
I happen to agree. But I think we should set some sort-of "deadline" on
this. Ie, if it doesn't hold up beta 1, then we should have it done by
beta 2. How does that sound for a compromise?
> 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.
>
What's wrong with my interfaces? ;-D
-Sterling
--
"Backups are for wimps. Real men upload their data to an FTP site and have
everyone else mirror it."
- Linus Torvalds
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
