Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116056
MIME-Version: 1.0
References: <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAAKU0unuauCu+WscxLSKRpbqTAWb9F8gCF2=UiAA2xc15CL5XA@mail.gmail.com> <DM6PR07MB6618C99264E6155695D21C50F9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB6618C99264E6155695D21C50F9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Fri, 17 Sep 2021 00:48:38 -0400
Message-ID: <CAKuGYLRd2e5V+do7xoNt43xp1uj6Cp+V2SUPWYX3GWyHZROy_A@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b46ffe05cc29a57d"
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: matthewmatthew@gmail.com (Matthew Brown)

--000000000000b46ffe05cc29a57d
Content-Type: text/plain; charset="UTF-8"

On Thu, 16 Sept 2021 at 23:33, tyson andre <tysonandre775@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 <tysonandre775@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
>
>

--000000000000b46ffe05cc29a57d--