Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112861
To: Rowan Tommins <rowan.collins@gmail.com>, internals@lists.php.net
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>
Message-ID: <264023c8-e0d1-666b-f906-c7bc821ed2df@processus.org>
Date: Wed, 13 Jan 2021 10:16:29 +0100
MIME-Version: 1.0
In-Reply-To: <39ccd4f9-cb63-549f-d34e-0c5e473598a2@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Allow object keys in arrays
From: pierre-php@processus.org ("Pierre R.")

Le 13/01/2021 à 10:08, Rowan Tommins a écrit :
> 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.
>
>
> Regards,

Hello,

Instead of trying to restrict types that can be used as keys, may be 
this should be the time to have enumerables, lists, maps, vectors, sets, 
types, dictionaries, ... in PHP standard library ? A third party tool 
such as PHP-DS should be part of core API instead of being a third party 
extension.

Arrays are arrays, but the more we add features in a single polymorphic 
data structure such as this, the less code is readable and 
comprehensible. We use arrays everywhere as soon as we need a list or a 
map, a vector, a set, a list, a dictionary, a data structure that's not 
an object, etc... that isn't built using a generator, and it becomes a 
serious mess. It's weakly typed, it's not explicit about the intent, in 
some case, I guess specific data structure would be much faster as well.

I think adding this new feature is really cool, but having a complete 
API around iterable with different types for different use cases would 
be much better in my opinion.

I know it's not going to happen soon, just saying for the sake of the 
conversation, but PHP arrays are really powerful, and insanely 
polymorphic, and they do way too much in my opinion.

Regards,

Pierre