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:
-
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.) -
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
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:
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.)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
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 ircmaxell@gmail.comwrote:
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 rasmus@mindplay.dk
wrote: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:
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.)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
--
Etienne Kneuss
http://www.colder.ch
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 ircmaxell@gmail.comwrote:
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 rasmus@mindplay.dk
wrote: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:
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.)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
--
Etienne Kneuss
http://www.colder.ch
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
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.