Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125069
Precedence: bulk
MIME-Version: 1.0
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net> <AM8P250MB01706B1541E1283F4065B94AE28C2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
In-Reply-To: <AM8P250MB01706B1541E1283F4065B94AE28C2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Tue, 20 Aug 2024 15:01:28 +0200
Message-ID: <CAP1Jc11djBvAkWgMwM-SzUQyW4AQ+TUDtLNKmyFNCmbJvKW+WA@mail.gmail.com>
Subject: Re: [PHP-DEV] State of Generics and Collections
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Bob,

On Tue, Aug 20, 2024 at 12:18=E2=80=AFAM Bob Weinand <bobwei9@hotmail.com> =
wrote:
> The fluid Arrays section says "A PoC has been implemented, but the perfor=
mance impact is still uncertain". Where may I find that PoC for my curiosit=
y? I'm imagining the implementation of the array types as a counted collect=
ion of types of the entries. But without the PoC I may only guess.

I may publish the PoC at some point, but in the meantime here is a
short description of how it's implemented:

- The zend_array has a zend_type member representing the type of its elemen=
ts
- Everytime we add or update a member, we union its type with the
array type. For simple types it's just a |=3D operation. For arrays with
a single class it's also simple. For complex types it's more expensive
currently, but it may be possible to cache transitions to make this
cheaper.
- Updating the array type on deletes requires to either maintain a
counter of every type, or to re-compute the type entirely everytime.
Both are probably too expensive. Instead, we don't update the type on
deletes, but we re-compute the type entirely when a type check fails.
This is based on two hypotheses: 1. A delete rarely changes an array's
type in practice, and 2. Type checks rarely fail
- References are treated as mixed, so adding a reference to an array
or taking a reference to an element changes its type to mixed. Passing
an array<mixed> to a more specific array<something> will cause a
re-compute, which also de-refs every reference.
- Updating a nested element requires updating the type of every parent

> It also says "Another issue is that [...] typed properties may not be pos=
sible.". Why would that be the case? Essentially a typed property would jus=
t be a static array, which you describe in the section right below.

It becomes complicated when arrays contain references or nested
arrays. Type constraints must be propagated to nested arrays, but also
removed when an array is not reachable via a typed property anymore.

E.g.

class C {
    public array<array<int>> $prop;
}

$a =3D &$c->prop[0];
$a[] =3D 'string'; // must be an error
unset($c->prop[0]);
$a[] =3D 'string'; // must be accepted

$b =3D &$c->prop[1];
$b[] =3D 'string'; // must be an error
$c->prop =3D [];
$a[] =3D 'string'; // must be accepted

I don't remember all the possible cases, but I didn't find a way to
support this that didn't involve recursively scanning an array at some
point. IIRC, without references it's less of an issue, so a possible
way forward would be to forbid references to members of typed
properties. Unfortunately this breaks pass-by-reference, e.g.
`sort($c->prop)`. out/inout parameters may be part of a solution, but
with more array separations than pass-by-ref.

Best Regards,
Arnaud