> I'm not sure how I came to that conclusion - did the description change > since I looked at it?
Maybe a little bit but not very much, if at all. > 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. Actually, this is ENTIRELY about foreach. You can currently return an object as a key from an iterator with no problems if you call the method. The problem is that the foreach code takes that value and coerces it to a string or integer. In the case of objects and arrays as keys it fails. We want the foreach to leave it alone and simply allow us to expose the key as an object or array. > 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. Having multiple interfaces that the engine uses to iterate in a foreach sounds like a bad idea to me. It's complicated enough as it currently is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
