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 <ircmax...@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 <ras...@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
