> 
>> I actually like the idea of flags added to `is_array()` for this.
>> 
>> Something like:
>> 
>>     is_array($value, ZERO_INDEXED | ASSOCIATIVE | INTEGER_INDEXED)
>> 
>> I’m not suggesting these names; they’re for illustration only.
> 
> I'm strongly opposed to adding any flags to is_array - keeping basic type 
> checks simple would help in learning/reading/remembering the language,
> has a small impact on performance for calls that aren't unambiguously 
> qualified (especially if using both), and it makes it harder to see issues 
> like
> `is_array(really_long_multiline_call(arg1, arg2, ZERO_INDEXED))`

tl;dr: How often do we find ourselves needing to check if an array uses ordered 
integer keys?? Compared to just forcing the passing through array_values?? For 
my implementation it’s only there because I’m experimenting with separating the 
three main types (for me): PHP unordered mixed keys, 
string-only-unordered-keys, and int-only-ordered-base-0-keys.

Under most circumstances I would strongly agree. With that said, I think 
requiring a certain arrangement of keys is a rare case; presumption being a 
solution would be in place if it wasn’t. Further, I think there are quite a few 
options to manipulate keys and we have 20+ years of linguistic baggage. 

Thought exercise I’m going through that would let userland opt-in to the 
complexity of further restricting the type-checkable PHP array with possible 
flags (just to continue the exercise):

1. PHP_STD_ARRAY: unordered map with keys that are strings, integers, or both - 
default...no BC, no additional learning curve except when users want to be more 
specific; all systems normal.
2. STRING_KEYS: all the keys are strings.
3. INT_KEYS: all the strings are integers.
4. ORDERED_ASC: keys are ordered from least to greatest (string or int).
5. ORDERED_DESC: keys are ordered from greatest to least.
4. INT_KEYS_BASE_ZERO: the first key is 0 (??)

I might be missing some cases, but this would cover current PHP array; the 
ability for users to sort on keys, not values; and wouldn’t require additional 
function or named thing as PHP “array” can be any of those things and it’s more 
a matter of whether users want to be more restrictive and why.

My use case for wanting this is pretty much to be more opinionated in my 
library and make a hard distinction between a base-0-int-ordered-array and an 
string-unordered-array. My PHP-like variant is actually call List, funny enough 
- with the ability to make it an array (array_values) or a dictionary 
(prepending int indexes with a letter to address dynamic casting). 

And, again, I’ve never had to run a check really - because if I need a “pure 
array” - I run array_values.

I’m cautious about introducing a new name against a known type as abstract as 
PHP array - which can be just about any combination of key-value pair 
constructs. 

If introducing a new name, I would hope to introduce a new type as well - even 
if under the hood it’s using checks against the more generic PHP array.

function hello(list $my_list_maybe)

The hope isn’t that the flags become a permanent fixture but allow better 
visibility into what userland wants from arrays without adding to the SL and 
without users needing to change their current mental models - do a lot of us 
*want* to have this ability (verify the metadata on keys of an array)?? Or is 
it just a fringe group of pedantic experimenters like me?? :)

Cheers,
Josh 
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to