Re: RFC: Add `final class Vector` to PHP

Hi Levi Morrison, > I'm okay with a final Vector class in general. I don't love the > proposed API but don't hate it either. Feedback on that at the end. > > What I would _love_ is a vec type from hacklang, which is > similar to > this but pass-by-value, copy-on-write like an array. Of course, this > would require engine work and I understand it isn't as simple to add. Yeah, as mentioned in https://wiki.php.net/rfc/vector#adding_a_native_type_instead_is_vec , it would require a massive amount of work. - A standard library for dealing with vec, filtering it, etc - Userland libraries and PECLs would need to deal with a third complex type different from array/object that probably couldn't be implicitly - Extensive familiarity with opcache and the JIT for x86 and other platforms beyond what I have - Willingness to do that with the uncertainty the final implementation would get 2/3 votes with backwards compatibility objections, etc. > Feedback on API: > > -  indexOf returning false > instead of null when it cannot be > found. If we are keeping this method (which I don't like, because > there's no comparator), please return null instead of > false. The > language has facilities for working with null like ??, so > please > prefer that when it isn't needed for BC (like this, this is a new > API). I hadn't thought about that - that seems reasonable since I don't remember anything else adding indexOf as a method name. > - contains also doesn't have a comparator. I was considering proposing ->any(callable) and ->all(callable) extensions if this passed. I'm not quite sure what you mean by a comparator for contains. There'd have to be a way to check if a raw closure is contained. > -  Similarly but less strongly, I don't like the filter callable > returning mixed -- please just make it > bool. The filter callable is something that would be passed into the filter function. The return value would be checked for truthiness. The phpdoc in the documentation could be changed, but that wouldn't change the implementation. > - I don't know what setSize(int $size) does. What does it > do if the > current size is less than $size? What about if its current size > is > greater? I suspect this is about capacity, not size, but without docs > I am just guessing. It's the same behavior as https://www.php.net/manual/en/splfixedarray.setsize.php . It's about size, not capacity. > Change the size of an array to the new size of size. > If size is less than the current array size, any values after the new size will be discarded. > If size is greater than the current array size, the array will be padded with null values. I'd planned to add phpdoc documentation and examples before starting a vote to document the behavior and thrown exceptions of the proposed methods. Thanks, Tyson