On Thu, 16 Sept 2021 at 23:33, tyson andre <tysonandre...@hotmail.com> wrote:
> 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. > I feel like the standard library could be added in userland first, and then corresponding faster implementations could arrive in the std lib. But the last point is a really important one, and feels like a weakness in the RFC process. I know RFCs without implementations are generally frowned upon, but if 2/3rds of the community agreed that they wanted some sort of vec[] support in theory, it might then free up the implementer(s) to take a more granular approach to supporting vec. It could, for example, be an experimental feature for a minor version. Best wishes, Matt On Thu, 16 Sept 2021 at 23:33, tyson andre <tysonandre...@hotmail.com> wrote: > 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 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
