Re: [RFC] Add is_list(mixed $value): bool to check for list-like arrays
| From: | tyson andre | Date: | Sun, 20 Dec 2020 20:09:39 +0000 |
| Subject: | Re: [RFC] Add is_list(mixed $value): bool to check for list-like arrays | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112566@lists.php.net to get a copy of this message | ||
Hi Larry Garfield,
> Well, since I'm quoted... :-)
>
> I'm fine with this, but have one question and one correction:
>
> * If we do eventually end up with list/vec types, would the naming here conflict at all? Or
> would it cause confusion and name collision? (Insert name bikeshedding here.)
>
> * The last quote, from me, has a small error. The last sentence shouldn't be a bullet
> point but its own paragraph, after the list is complete.
Yes, there's definitely the potential for naming conflicts if the type is called
list
but not if it's called vec/vector/varray similar to https://docs.hhvm..com/hack/built-in-types/arrays
- I'd prefer the latter if there was a viable implementation.
I should note that in the discussion section.
If the type is named list instead of vector and ends up incompatible with
arrays,
there'd need to be an is_list_type($val) or $val is list
or some other new type check with a less preferable name.
If it's compatible with arrays/lists
(e.g. only checked during property assignment, passing in arguments, and returning values), then it
wouldn't be an issue.
- is_array_list() or is_array_and_list() or is_values_array() would avoid some of that ambiguity but
would be much more verbose
Providing objects with APIs similar to the external PECL https://www.php.net/manual/en/class.ds-vector.php
and the SPL may be easier to adopt because it can be polyfilled,
but there's the drawback that there aren't the memory savings from copy-on-write and that
there's the performance overhead of method calls to offsetGet(), etc.
I'd expect the addition of a separate/incompatible vec type to be a massive undertaking, and
possibly unpopular if it splits the language.
In Hack/HHVM, it was practical for users to adopt because HHVM is bundled with a typechecker that
checks that the uses
are correct at compile time - because PHP has no bundled type checker, a new type would potentially
cause a lot of unintuitive behaviors.
I fixed the formatting of the quote.
-- Tyson