# rfc:foreach-non-scalar-keys - Thread: https://externals.io/message/65371 - Original archive: https://news-web.php.net/php.internals/65371 - Started by Rasmus Schultz on 2013-01-29T13:03:40+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #65371 — Rasmus Schultz — 2013-01-29T13:03:40+00:00 URL: https://externals.io/message/65371#65371 I just saw this RFC: https://wiki.php.net/rfc/foreach-non-scalar-keys By "non-scalar", presumably we're talking about objects? In the numbers that e.g. resources typically get used, having a collection indexed by resources would seem like an extremely exotic need. Moreover, we already have this: http://php.net/manual/en/class.splobjectstorage.php I just want to note that, while allowing non-scalar keys may seem like a natural addition, we're not talking about a simple change to the foreach statement - we're talking about a fundamental change to the array type. So I will point out two things: 1. Allowing non-scalar keys in arrays takes away an error-condition that would normally be reported: accidentally using an object as a key (which could even work in some cases, and could cause objects not to be garbage collected.) 2. SplObjectStorage already solves this problem - minus e.g. resources, but you could put your resources in an object and address that (very exotic) need. Bottom line, I'm not in favor of this idea - it just doesn't seem necessary or really even beneficial to me. - Rasmus Schultz --- ## #65374 — Anthony Ferrara — 2013-01-29T13:15:28+00:00 URL: https://externals.io/message/65371#65374 · In reply to: #65371 Rasmus, Relax. It hasn't even been proposed yet. Give the author some time to finish the RFC before proposing it here, and then we can discuss it... Anthony > I just saw this RFC: > > https://wiki.php.net/rfc/foreach-non-scalar-keys > > By "non-scalar", presumably we're talking about objects? In the numbers > that e.g. resources typically get used, having a collection indexed by > resources would seem like an extremely exotic need. > > Moreover, we already have this: > > http://php.net/manual/en/class.splobjectstorage.php > > I just want to note that, while allowing non-scalar keys may seem like a > natural addition, we're not talking about a simple change to the foreach > statement - we're talking about a fundamental change to the array type. > > So I will point out two things: > > 1. Allowing non-scalar keys in arrays takes away an error-condition that > would normally be reported: accidentally using an object as a key (which > could even work in some cases, and could cause objects not to be garbage > collected.) > > 2. SplObjectStorage already solves this problem - minus e.g. resources, but > you could put your resources in an object and address that (very exotic) > need. > > Bottom line, I'm not in favor of this idea - it just doesn't seem necessary > or really even beneficial to me. > > - Rasmus Schultz --- ## #65382 — Etienne Kneuss — 2013-01-29T13:34:07+00:00 URL: https://externals.io/message/65371#65382 · In reply to: #65374 This RFC is not about arrays. The proposed change is to allow Iterator::key() to return things other than int/strings. Consequently, it would mean foreach($iterable as $key=>$foo) { $key can be an object here }. SplObjectStorage "solves" it by returning an array() of object-key/object-data as *value*, and an integer as key, which is not ideal. Best, On Tue, Jan 29, 2013 at 2:15 PM, Anthony Ferrara wrote: > Rasmus, > > Relax. It hasn't even been proposed yet. Give the author some time to > finish the RFC before proposing it here, and then we can discuss it... > > Anthony > > > On Tue, Jan 29, 2013 at 8:03 AM, Rasmus Schultz > wrote: > > > […] > but > > […] > necessary > > […] > -- Etienne Kneuss http://www.colder.ch --- ## #65547 — Rasmus Schultz — 2013-02-01T00:05:24+00:00 URL: https://externals.io/message/65371#65547 · In reply to: #65382 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.) > This RFC is not about arrays. > > The proposed change is to allow Iterator::key() to return things other > than int/strings. Consequently, it would mean foreach($iterable as > $key=>$foo) { $key can be an object here }. > > SplObjectStorage "solves" it by returning an array() of > object-key/object-data as *value*, and an integer as key, which is not > ideal. > > Best, > > > On Tue, Jan 29, 2013 at 2:15 PM, Anthony Ferrara wrote: > > > […] > > > > -- > Etienne Kneuss > http://www.colder.ch --- ## #65548 — Nikita Popov — 2013-02-01T00:34:23+00:00 URL: https://externals.io/message/65371#65548 · In reply to: #65547 > 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 --- ## #65549 — Levi Morrison — 2013-02-01T02:31:17+00:00 URL: https://externals.io/message/65371#65549 · In reply to: #65547 > 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.