Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112920
MIME-Version: 1.0
References: <CAF+90c8Euq9nTMeoeUJ3a6s3wyj_DqbOeXoh07oDeUy6PeCefA@mail.gmail.com>
 <CADyq6sKx0wnq__p-dy3=bovHZ=Uzu=QN2Ko6OLmiGj47BrBNeQ@mail.gmail.com>
 <CAPyj-LAciv_XS+ML2FnbkXeZRQONOe-qFm9d6_J+OdVK2AOyOw@mail.gmail.com>
 <CADyq6sJAD9-P9bE5S4Td3kjMoXjtzy6uhEwzb6e4jgpnVz1DBA@mail.gmail.com> <39ccd4f9-cb63-549f-d34e-0c5e473598a2@gmail.com>
In-Reply-To: <39ccd4f9-cb63-549f-d34e-0c5e473598a2@gmail.com>
Date: Mon, 18 Jan 2021 15:33:55 +0100
Message-ID: <CAF+90c-3dxV4=HQoZ9R163mGUMvn_+DgsLEY8DuhP2jDL+GeGw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008b1f3505b92d9d2e"
Subject: Re: [PHP-DEV] [RFC] Allow object keys in arrays
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000008b1f3505b92d9d2e
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 13, 2021 at 10:08 AM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 12/01/2021 16:51, Marco Pivetta wrote:
> > Whether the problem can be mitigated is what should be discussed, but the
> > problem is objectively there.
>
>
> Hi all,
>
> Like others, I like the *idea* of object keys, but worry about its
> practical impact.
>
> A few scatter-gun thoughts on possible approaches, I don't think any of
> them is the solution, but maybe they'll spark someone else to further
> ideas:
>
>
> - Only allow objects that are "stringable" (i.e. implement __toString),
> but don't actually call it. This retains the safety of code using
> "(string)$key", but not code passing to a constraint of "string|int".
> (It also means enums will all have to have an __toString, which might be
> a price worth paying.)
>
> - Create a new type, which is like an array but allows object keys, with
> its own literal syntax. e.g.
>
> $hash = hash['foo' => 42, $someObject => 69];
> assert(is_array($hash) === false);
> assert(is_iterable($hash) === true);
>
> - Invent a syntax for initialising a custom collection object from a
> literal with arbitrary keys and values, but not actually initialise it
> as an array. Even without generics, this would make it much more
> attractive to replace more arrays with specific collection types.
>

I don't think a separate dictionary type would really help (in the context
of this discussion). If you're working with arrays, you already either
treat it as a vector (in which case the keys are irrelevant) or as a
dictionary (in which case you would need to deal with object keys
regardless of whether you call it "array" or "dict"). I think a dedicated
dictionary type can have other benefits (primarily removing numeric string
-> int canonicalization), but I don't think that distinguishing allowed key
types based on it is a good idea. (If we introduced such a type, I would
expect it to have the same key requirements as normal arrays, because both
types would have to be strongly interoperable, and allow mostly seamless
conversions.)

Regards,
Nikita

--0000000000008b1f3505b92d9d2e--