Hi Rowan, On Sat, Jan 17, 2015 at 8:43 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> My concern is, at what cost? Given how rarely used the internal pointer is, > are we carrying around a chunk of extra memory with every array just on the > off-chance that it will be used, or is there some magic that makes it > zero-width until it's needed? > > Reusing it for foreach makes perfect sense if it increases performance for > the majority of cases, and the only way to cover every edge-case like the > one at the top of this thread would be to ban that optimisation outright. > If there's some way of separating things such that the rarely used > constructs take the performance hit, I'm all for it, though. > External position pointer needs a little more memory for sure. However, external position pointer is used all over the place in standard and other modules. I agree that some benchmark should be taken before we proceed. Alternatively, we could achieve consistency the other way round, by making > foreach() reset the internal pointer even when it *doesn't* use it, and > documenting that fact like we do for certain array functions. Code relying > on the current behaviour when mixing them is probably buggy anyway, because > it is not well-defined, so the BC concern should be low. > IIRC, there were discussions when foreach is added that point out internal position pointer usage. Before foreach, everyone was using current()/next()/reset(). I think the reason foreach sets internal position pointer to the end was the code used in those days. It was not a technical/performance reasons, wasn't it? I don't remember well because it was more than 10 years ago. Anyone? IIRC, foreach was introduced by Andi. I think foreach used external position pointer and didn't touch internal position pointer at all with his first proposal. Please correct me if I'm wrong. As for nesting, I think PHP is doing the right thing for plain arrays and > non-rewindable integrators, because I would expect a for each loop to start > at the beginning, thus have an implicit reset/rewind. The rewindable > behaviour is awkward, though - intuitively, the iteraror needs to be able > to track multiple positions simultaneously, which isn't guaranteed by the > interface design. Maybe an error should be issued if the integrator is > already subject of a foreach loop? > Iterator is headache, I agree. Iterator nesting may be detected by a flag easily, but it may be better to generate independent iterators for each "foreach". Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
