Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116058
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 12:43:32 +0700
Message-ID: <CAEZPtU7oJRYxzJWu0Y_hAnuOroowve1ziL4rVr5ui4TRGtAk_g@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/mixed; boundary="0000000000000d4e2905cc2a6af0"
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: pierre.php@gmail.com (Pierre Joye)

--0000000000000d4e2905cc2a6af0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Tyson,

Vector support would be very good. JIT can do a lot with them if we
have a clean Vector implementation, or even without JIT.

What is your base inspiration for Vector? I do like the pretty
standard C++ Vector implementation:

https://www.cplusplus.com/reference/vector/vector/

Where a Vector is initalizied with:

$myIntVector =3D vector<Integer>;

What is key for performance is also the alloc/realloc/free strategy.
In C++ (or most C or other languages custom) gives control to the
creators to define max size, capacity, etc.

If a non typed Vector is the goal, then I am less in need of it, still
good to have but not as good as a clear pure Vector support :).

Also I think it will be very good to have more details about what this
RFC proposes in the RFC. It is kind of hard to follow right now, with
all external links. RFCs are better if they act as a real
specification :)

Best,
Pierre

On Fri, Sep 17, 2021 at 9:10 AM tyson andre <tysonandre775@hotmail.com> wro=
te:
>
> 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 inte=
rnal array HashTable API to the PHP's internals and PECLs, additional memor=
y is needed to track keys (https://www.npopov.com/2014/12/22/PHPs-new-hasht=
able-implementation.html - around twice as much as is needed to just store =
the values due to needing 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 lea=
st 8 elements to make the initial resizing more efficient, potentially wast=
ing 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 exceedi=
ng 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` f=
or use cases
>    where objects are easier to use than arrays - e.g. variable sized coll=
ections (For lists of values) that can be passed by value to be read and mo=
dified.
> 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 `\Vecto=
r`).
> (That is a PECL I created earlier this year for future versions of iterab=
le proposals, common data structures such as Vector/Deque, and less commonl=
y used data structures that may be of use in future work on implementing ot=
her data structures)
>
> Thanks,
> Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>


--=20
Pierre

@pierrejoye | http://www.libgd.org

--0000000000000d4e2905cc2a6af0--