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,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
