On Fri, Feb 1, 2013 at 1:05 AM, Rasmus Schultz <ras...@mindplay.dk> wrote:
> I'm not sure how I came to that conclusion - did the description change > since I looked at it? > > I guess the title "foreach-non-scalar-keys" may have thrown me off - so > this isn't about arrays, or really even about foreach, but about the > Iterator interface. I'm not against that at all. > > I would suggest considering the addition of a second, distinct interface - > rather than a modification to the existing interface, which already does > what it's supposed to and works well, including the warning, which is > appropriate for the intended use of that interface with the foreach > statement. > > This alternative interface could have the opposite behavior - issuing a > warning if the returned key is not an object. I don't think there's a > legitimate use-case where mixing scalar and object keys would be a good > idea? (if there were, a single interface might be the only way to go.) > Please, don't make this more complicated than it is. This is just about removing an arbitrary engine limitation. And yes, obviously mixing different keys has applications, e.g. consider implementing a generalized hash type. It makes no sense whatsoever to implement the same thing with two classes implementing different interfaces. The only reason why this needs discussion is that allowing non string/int keys requires a change in the internal iterator API. Nikita
