Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124114
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <bc6276a6-f130-489e-bbb1-53e11d4b5cc2@app.fastmail.com>
In-Reply-To: 
 <CABdc3Wqzt+S2xL-=dVH1Ae0oQLR5jAMaBEex5NemKPb9rBx9MQ@mail.gmail.com>
References: <be7bc3e2-ce2b-422f-9f3a-743829f1e1be@scriptfusion.com>
 <A8ECC81C-99C7-47FB-B0C0-C2166F1AA43E@miles.systems>
 <CAAGC1Ov8LniFwvB+Bs93hEv1wSXZ9xJ3SJDpYYzzTcEW2Yt-TQ@mail.gmail.com>
 <CAAKU0u=w12chvWGsbCyuiXp14RcQ0boDd7i7MmeooWCOd9Cn+g@mail.gmail.com>
 <4ECBB519-B129-426F-93AE-33738A1ABA06@miles.systems>
 <CABdc3Wqzt+S2xL-=dVH1Ae0oQLR5jAMaBEex5NemKPb9rBx9MQ@mail.gmail.com>
Date: Sun, 30 Jun 2024 18:44:51 +0200
To: 
 =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>,
 "Richard Miles" <richard@miles.systems>
Cc: "php internals" <internals@lists.php.net>,
 "Derick Rethans" <derick@php.net>,
 "Levi Morrison" <levi.morrison@datadoghq.com>
Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays
Content-Type: multipart/alternative;
 boundary=44f1ed816e454b65a00f03a6bb628668
From: rob@bottled.codes ("Rob Landers")

--44f1ed816e454b65a00f03a6bb628668
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sun, Jun 30, 2024, at 18:13, Micha=C5=82 Marcin Brzuchalski wrote:
> Hi Richard,
>=20
> czw., 27 cze 2024, 22:33 u=C5=BCytkownik Richard Miles <richard@miles.=
systems> napisa=C5=82:
>>=20
>> > I worked with Joe Watkins to do a proof-of-concept for generic trai=
ts.
>> > It's a bit old since it's from 2017, but could be a useful starting
>> > point if you are serious about pursuing this idea:
>> >=20
>> > https://github.com/php/php-src/compare/master...morrisonlevi:php-sr=
c:parameterized_traits
>>=20
>>=20
>> I=E2=80=99m also interested in this; it will help see branches like t=
hese.
>> Did you ever get the POC working? What did you feel like was the bigg=
est hurdle?
>=20
> There even was an RFC in voting which Joe implemented and it addresses=
 nearly what is discussed it this thread https://wiki.php.net/rfc/arrayof
>=20
> I must admit that the collection<Dict> proposal is bit too complex to =
address such tiny but powerfully in my opinion functionality which is ty=
ped array. What Derick showed looks more like generic collection and suc=
h require declaring it's type. In my opinion this is way too mush hassle=
 to declare as many collection types as many usages in application. Also=
 two collection types with the same collection item type will not be com=
patible from type perspective. While typed array seems much more clear a=
nd compatible in all places where typed array is needed without declarin=
g separate type for each usage.
>=20
> If I were to choose between typed-array and collection like Derick sho=
wed a little bit I'd choose typed arrays definitely as a first feature t=
o be merged into PHP.
>=20
> Cheers,
> Micha=C5=82 Marcin Brzuchalski=20
>>=20

Hello again,

I=E2=80=99ve been thinking about this off-and-on. One of the issues brou=
ght up in this thread around type-checking arrays is their unboundedness=
, and the performance implications of that. Instead of typed arrays, why=
 not start with typed Tuples?=20

Tuples are nice because they are bounded, they can probably act like arr=
ays (possibly even cast to them and vice-versa).

I=E2=80=99m imagining something like (to borrow from another RFC):

function bcdivmod(=E2=80=A6): Tuple<int, int>

which can be destructured just like an array. From the perspective of us=
erland, they are bounded, typed arrays.

=E2=80=94 Rob
--44f1ed816e454b65a00f03a6bb628668
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Sun, Jun 30, 2024, at 18:13, Micha=C5=82 Marcin Brzuch=
alski wrote:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><di=
v dir=3D"auto"><div>Hi Richard,<br></div><div><br></div><div class=3D"qt=
-gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"qt-gmail_attr">czw.=
, 27 cze 2024, 22:33 u=C5=BCytkownik Richard Miles &lt;richard@miles.sys=
tems&gt; napisa=C5=82:<br></div><blockquote class=3D"qt-gmail_quote" sty=
le=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4, 204, 204);padding-left:1ex;"><div><br></div><div>&gt; I worked with J=
oe Watkins to do a proof-of-concept for generic traits.<br></div><div> &=
gt; It's a bit old since it's from 2017, but could be a useful starting<=
br></div><div> &gt; point if you are serious about pursuing this idea:<b=
r></div><div> &gt; <br></div><div> &gt; <a href=3D"https://github.com/ph=
p/php-src/compare/master...morrisonlevi:php-src:parameterized_traits" re=
l=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/php/php=
-src/compare/master...morrisonlevi:php-src:parameterized_traits</a><br><=
/div><div> <br></div><div> <br></div><div> I=E2=80=99m also interested i=
n this; it will help see branches like these.<br></div><div> Did you eve=
r get the POC working? What did you feel like was the biggest hurdle?<br=
></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
There even was an RFC in voting which Joe implemented and it addresses n=
early what is discussed it this thread&nbsp;<a href=3D"https://wiki.php.=
net/rfc/arrayof">https://wiki.php.net/rfc/arrayof</a><br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">I must admit that the collection&lt;D=
ict&gt; proposal is bit too complex to address such tiny but powerfully =
in my opinion functionality which is typed array. What Derick showed loo=
ks more like generic collection and such require declaring it's type. In=
 my opinion this is way too mush hassle to declare as many collection ty=
pes as many usages in application. Also two collection types with the sa=
me collection item type will not be compatible from type perspective. Wh=
ile typed array seems much more clear and compatible in all places where=
 typed array is needed without declaring separate type for each usage.<b=
r></div><div dir=3D"auto"><br></div><div dir=3D"auto">If I were to choos=
e between typed-array and collection like Derick showed a little bit I'd=
 choose typed arrays definitely as a first feature to be merged into PHP=
.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Cheers,<br></di=
v><div dir=3D"auto">Micha=C5=82 Marcin Brzuchalski&nbsp;<br></div><div c=
lass=3D"qt-gmail_quote" dir=3D"auto"><blockquote class=3D"qt-gmail_quote=
" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left=
:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204, 204, 204);padding-left:1ex;"><br></blockquote></div></div></bloc=
kquote><div><br></div><div>Hello again,<br></div><div><br></div><div>I=E2=
=80=99ve been thinking about this off-and-on. One of the issues brought =
up in this thread around type-checking arrays is their unboundedness, an=
d the performance implications of that. Instead of typed arrays, why not=
 start with typed Tuples? <br></div><div><br></div><div>Tuples are nice =
because they are bounded, they can probably act like arrays (possibly ev=
en cast to them and vice-versa).<br></div><div><br></div><div>I=E2=80=99=
m imagining something like (to borrow from another RFC):<br></div><div><=
br></div><div>function bcdivmod(=E2=80=A6): Tuple&lt;int, int&gt;<br></d=
iv><div><br></div><div>which can be destructured just like an array. Fro=
m the perspective of userland, they are bounded, typed arrays.</div><div=
><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html=
>
--44f1ed816e454b65a00f03a6bb628668--