I appreciate this idea as I ran into the same issue with one of my libraries when I wrote similar rules.
Granted, I’m using “array” and “dictionary” not “list” as both terms seem common to the community and used to distinguish the two. But that’s semantics, which I’m sure will be discussed at a later date; short version: is_array and is_dict(ionary). 1. Sequential using int starting at 0 2. Non-sequential using strings for all keys 3. Standard PHP array with potential mixed keys. Cheers, Josh > On Dec 20, 2020, at 2:09 PM, tyson andre <tysonandre...@hotmail.com> wrote: > > 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 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
