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

Reply via email to