Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116049
MIME-Version: 1.0
References: <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Fri, 17 Sep 2021 04:19:03 +0200
Message-ID: <CADyq6sLv=YAu9p5fq3HW0uN+mZhj-UiQL-CQhEM9MopE7cLBHQ@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cc6d8f05cc278ea0"
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: ocramius@gmail.com (Marco Pivetta)

--000000000000cc6d8f05cc278ea0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Tyson,

Would it perhaps make sense to drag in php-ds, which has matured quite a
bit over the years? I'm referring to:
https://www.php.net/manual/en/class.ds-sequence.php

Is what you are suggesting with `Vector` different from it?

Note: For some reason, I can't quote your post and then reply, so it will
be a top-post =F0=9F=A4=B7=E2=80=8D=E2=99=80=EF=B8=8F

On Fri, 17 Sep 2021, 04:10 tyson andre, <tysonandre775@hotmail.com> wrote:

> Hi internals,
>
> I've created a new RFC https://wiki.php.net/rfc/vector proposing to add
> `final class Vector` to PHP.
>
> PHP's native `array` type is rare among programming language in that it i=
s
> used as an associative map of values, but also needs to support lists of
> values.
> In order to support both use cases while also providing a consistent
> internal array HashTable API to the PHP's internals and PECLs, additional
> memory is needed to track keys (
> https://www.npopov.com/2014/12/22/PHPs-new-hashtable-implementation.html
> - around twice as much as is needed to just store the values due to needi=
ng
> space both for the string pointer and int key in a Bucket, for
> non-reference counted values)).
> Additionally, creating non-constant arrays will allocate space for at
> least 8 elements to make the initial resizing more efficient, potentially
> wasting memory.
>
> It would be useful to have an efficient variable-length container in the
> standard library for the following reasons:
>
> 1. To save memory in applications or libraries that may need to store man=
y
> lists of values and/or run as a CLI or embedded process for long periods =
of
> time
>    (in modules identified as using the most memory or potentially
> exceeding memory limits in the worst case)
>    (both in userland and in native code written in php-src/PECLs)
> 2. To provide a better alternative to `ArrayObject` and `SplFixedArray`
> for use cases
>    where objects are easier to use than arrays - e.g. variable sized
> collections (For lists of values) that can be passed by value to be read
> and modified.
> 3. To give users the option of stronger runtime guarantees that property,
> parameter, or return values really contain a list of values without gaps,
> that array modifications don't introduce gaps or unexpected indexes, etc.
>
> Thoughts on Vector?
>
> P.S. The functionality in this proposal can be tested/tried out at
> https://pecl.php.net/teds (under the class name `\Teds\Vector` instead of
> `\Vector`).
> (That is a PECL I created earlier this year for future versions of
> iterable proposals, common data structures such as Vector/Deque, and less
> commonly used data structures that may be of use in future work on
> implementing other data structures)
>
> Thanks,
> Tyson

--000000000000cc6d8f05cc278ea0--