Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.212.48 cause and error)
MIME-Version: 1.0
Date: Tue, 29 Jan 2013 08:03:40 -0500
Message-ID: <CADqTB_iD0kbqwQ5aLoLXZWdq+9r6jTg4WdCKdYkvsmgfd=ne+w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04389427cec11604d46d0531
Subject: rfc:foreach-non-scalar-keys
From: rasmus@mindplay.dk (Rasmus Schultz)

--f46d04389427cec11604d46d0531
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d04389427cec11604d46d0531--