Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65374
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_iD0kbqwQ5aLoLXZWdq+9r6jTg4WdCKdYkvsmgfd=ne+w@mail.gmail.com>
References: <CADqTB_iD0kbqwQ5aLoLXZWdq+9r6jTg4WdCKdYkvsmgfd=ne+w@mail.gmail.com>
Date: Tue, 29 Jan 2013 08:15:28 -0500
Message-ID: <CAAyV7nGpK3UysQ3ewEC051k9DnHAxwBjxFAK685-2gK9kwqzdg@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec54a3788fa165404d46d2fc1
Subject: Re: [PHP-DEV] rfc:foreach-non-scalar-keys
From: ircmaxell@gmail.com (Anthony Ferrara)

--bcaec54a3788fa165404d46d2fc1
Content-Type: text/plain; charset=ISO-8859-1

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:
>
> 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
>

--bcaec54a3788fa165404d46d2fc1--