Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123758
Precedence: bulk
MIME-Version: 1.0
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <02ee8831-43a0-4857-886e-7f54fb42a99d@varteg.nz> <CAB-Buja2B0_idnmjZFDNiQrGSRck-z-G7M1v8dNQ6ZyCf482OQ@mail.gmail.com>
 <CAPzBOBNLFmGESU-OEfp+ZVXdzKQ_H+yBT2Ak-hcrm1ZK25kUQA@mail.gmail.com>
 <7d825b1d-e584-4916-9435-3561b9c54c26@gmail.com> <CAPzBOBNLfccuXNzcsgf-2-JpJeGNXu2jVGsA-+Fkhbu0+sGBdA@mail.gmail.com>
 <CAP1Jc10RBiSY_bosS90LBxBjccj6_rNsr_f68yo8Rhos=axQJg@mail.gmail.com>
In-Reply-To: <CAP1Jc10RBiSY_bosS90LBxBjccj6_rNsr_f68yo8Rhos=axQJg@mail.gmail.com>
Date: Sat, 22 Jun 2024 22:15:17 +0200
Message-ID: <CAPzBOBM1ox1Bk0V37tin76Ofn_cDn5EHXgUga1Pss0LK7JGncA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: Arnaud Le Blanc <arnaud.lb@gmail.com>
Cc: Niels Dossche <dossche.niels@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Sat, Jun 22, 2024 at 8:59=E2=80=AFPM Arnaud Le Blanc <arnaud.lb@gmail.co=
m> wrote:
>
> On Fri, Jun 21, 2024 at 7:20=E2=80=AFPM Robert Landers <landers.robert@gm=
ail.com> wrote:
> > > > I'm always surprised why arrays can't keep track of their internal
> > > > types. Every time an item is added to the map, just chuck in the ty=
pe
> > > > and a count, then if it is removed, decrement the counter, and if
> > > > zero, remove the type. Thus checking if an array is `array<int>`
> > > > should be a near O(1) operation. Memory usage might be an issue (a
> > > > couple bytes per type in the array), but not terrible.... but then
> > > > again, I've been digging into the type system quite a bit over the
> > > > last few months.
> > >
> > > And every time a modification happens, directly or indirectly, you'll
> > > have to modify the counts too. Given how much arrays / hash tables ar=
e
> > > used within the PHP codebase, this will eventually add up to a lot of
> > > overhead. A lot of internal functions that work with arrays will need
> > > to be audited and updated too. Lots of potential for introducing bugs=
.
> > > It's (unfortunately) not a matter of "just" adding some counts.
> >
> > Well, of course, nothing in software is "just" anything.
>
> Counters are not cheap as we need one slot for each type in the array so =
we need a dynamic buffer and an indirection, plus absolutely every mutation=
 needs to update a counter, including writes to references. It is possible =
to remove the counters and to maintain an optimistic upper bound of the typ=
e (computing the type more precisely when type checking fails), but I feel =
this would not work well with pattern matching.

To me, that sounds kinda silly. PHP does reference counting and while
there is an overhead, it doesn't prevent us from using it...

Anyway, while you make a good point for the pathological case, I
suspect the impact to the popular case (mostly homogenous arrays), the
performance impact will be negligible compared to the productivity
impact of being able to type-check arrays.

>
> Also, a few things complicate this:
> - Nested writes like $a[0][0][0]=3D1 need to backtrack to update the type=
 of all parent arrays after the element is added/updated

Nesting could be forbidden, at least at first. I think saying
"array<array<array<int>>>" is forbidden is totally fine.

> - Supporting references to properties whose type is a typed array, or dim=
ensions of these properties, is very hard

Also, depends on the defined behavior? If you have a typed property
that is array<string> and you try to add an int to it ... it could
fail. Thus not being hard at all.

>
> Fixed-type arrays may be easier to support but there are important drawba=
cks in usability IMHO. This does not play well with CoW semantics.
>
> Best Regards,
> Arnaud

Robert Landers
Software Engineer
Utrecht NL