On Wed, Jun 26, 2024, at 19:57, Richard Miles wrote:
> “Array-application will also be pushed to future-scope”
> 
> 
> Dang, this is what I was looking forward to the most. Helping set some 
> precedent on this issue, and this is a solid start. I’ve been thinking about 
> what it would look like for strictly typed arrays in PHP for a while now. I 
> think a custom implantation like SqlObjectStorage or SplFixedArray could help 
> performance since we now have a fixed list and no need for a hash table, and 
> it may solve some complexity in implementation. This is slightly off-topic, 
> but if anyone is interested in working on a typed arrays initiative, please 
> contact me directly. 

Just a good ole' circular buffer would be nice for so many things (fiber 
microwork queues, etc) :)

That being said, you can abuse arrays to get better (or at least the same) 
performance of SPL for certain data structures (e.g., priority queues/heaps: 
https://withinboredom.info/2022/09/04/algorithms-in-php-priority-queues-and-heaps/
 -- the listing isn't complete or fully working, FWIW). Those little arrays 
have much power, and I love them for some tasks.

> 
> That said, I agree with Robert Landers, who wrote the following:
> 
> There's no need to use `?` to check for existence on a key, so this:
> 
> $arr is ['a' => string, ?'b' => string, ...];
> 
> should be this:
> 
> $arr is ['a' => string, 'b' => ?string, …];
> 
> ______
> 
> Chuck Adams cleared that up with:
> The first means b is an optional key, but if it’s there, can only be a 
> string. The second says b is a required key, but it may be a string or null. 
> If there were a binding involved, that determines the type of the binding in 
> incompatible ways.
> ______
> 
> I think there is a need to ensure a key does not exist even if we’re not 
> happy about this syntax, but if not having `$arr is ['a' => string, 'b' => 
> ?string, …]` would still make me very happy. 

The only time I can't think of this being important (whether or not a key 
exists) is during serialization/deserialization, where you may want to leave 
something its default value. In that case, you likely won't know what the keys 
are supposed to be in the first place (thus unable to use them in something 
like "is" or "as"). In the case that you did, this would be perfectly 
reasonable:

$keys = array_keys($arr) is [ "a", ?"b", ?"c"];

It's still weird-looking, but it tells you that the keys may or may not exist, 
and it is consistent with itself. However, what if the array is in a different 
order or missing keys (e.g., ["c", "a"])? You can see how this gets complicated 
pretty quickly. If I am getting hung up on $arr['non-existent-key'] technically 
being null, you can imagine how someone else -- maybe even me if I thought 
about it long enough -- would argue that ["a", ?"b", ?"c"] may or may not match 
["a", "c"] as the arguments for either way are pretty strong and the usecases 
for either way being just as valuable. It's a good call to punt it for deeper 
discussion later.

> 
> Best,
> 
> Richard Miles

Please remember to bottom-post ;)

— Rob

Reply via email to