> 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
> Ite
On Fri, Feb 1, 2013 at 1:05 AM, Rasmus Schultz 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 th
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 sugge
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 *va
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:
> I just saw this RFC:
>
> https://wiki.php.net/rfc/foreach-non-scalar-keys
>
> B
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:
