Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65547
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.128.179 cause and error)
MIME-Version: 1.0
In-Reply-To: <CACQesk5WGbU9heWqpcMJo-eOM-BbgHZ=d2cGCzU2hHcqFqzPcQ@mail.gmail.com>
References: <CADqTB_iD0kbqwQ5aLoLXZWdq+9r6jTg4WdCKdYkvsmgfd=ne+w@mail.gmail.com>
	<CAAyV7nGpK3UysQ3ewEC051k9DnHAxwBjxFAK685-2gK9kwqzdg@mail.gmail.com>
	<CACQesk5WGbU9heWqpcMJo-eOM-BbgHZ=d2cGCzU2hHcqFqzPcQ@mail.gmail.com>
Date: Thu, 31 Jan 2013 19:05:24 -0500
Message-ID: <CADqTB_iT=y76SRUQLiDczpNDdUQUP9ZNrgGYzmHycZDp5kyPJw@mail.gmail.com>
To: Etienne Kneuss <colder@php.net>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec5171e010aa3ca04d49e8053
Subject: Re: [PHP-DEV] rfc:foreach-non-scalar-keys
From: rasmus@mindplay.dk (Rasmus Schultz)

--bcaec5171e010aa3ca04d49e8053
Content-Type: text/plain; charset=ISO-8859-1

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.)


On Tue, Jan 29, 2013 at 8:34 AM, Etienne Kneuss <colder@php.net> wrote:

> 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.com>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 <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
>> >
>>
>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch
>

--bcaec5171e010aa3ca04d49e8053--