Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124127
Precedence: bulk
MIME-Version: 1.0
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>
 <4996ae09-e5eb-4a8b-90e2-7461805c4cb7@app.fastmail.com>
In-Reply-To: <4996ae09-e5eb-4a8b-90e2-7461805c4cb7@app.fastmail.com>
Date: Mon, 1 Jul 2024 06:48:15 +0200
Message-ID: <CABdc3Wph2TevxQrG6CWurj0svWAvX=mQ0T2R3yxCgQkr2wmdSA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d3188d061c284ee6"
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000d3188d061c284ee6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

pon., 1 lip 2024 o 03:01 Larry Garfield <larry@garfieldtech.com> napisa=C5=
=82(a):

> On Sun, Jun 30, 2024, at 11:13 AM, Micha=C5=82 Marcin Brzuchalski wrote:
> > Hi Richard,
> >
> > czw., 27 cze 2024, 22:33 u=C5=BCytkownik Richard Miles
> > <richard@miles.systems> napisa=C5=82:
> >>
> >> > I worked with Joe Watkins to do a proof-of-concept for generic trait=
s.
> >> > 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:
> >> >
> >> >
> https://github.com/php/php-src/compare/master...morrisonlevi:php-src:para=
meterized_traits
> >>
> >>
> >> I=E2=80=99m also interested in this; it will help see branches like th=
ese.
> >> Did you ever get the POC working? What did you feel like was the
> biggest hurdle?
> >
> > 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/arrayo=
f
> >
> > I must admit that the collection<Dict> proposal is bit too complex to
> > address such tiny but powerfully in my opinion functionality which is
> > typed array. What Derick showed looks 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 types as many usages in
> > application. Also two collection types with the same collection item
> > type will not be compatible from type perspective. While typed array
> > seems much more clear and compatible in all places where typed array is
> > needed without declaring separate type for each usage.
> >
> > If I were to choose 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.
> >
> > Cheers,
> > Micha=C5=82 Marcin Brzuchalski
>
> Contextual point: Nearly every other major language at this point that ha=
s
> a meaningful standard library has gone with a three-separate-object
> approach (Seq, Set, Dict, called various things).  At least Python,
> Javascript, Rust, Kotlin, and Swift, in my research.  (Go doesn't, but Go
> avoids having features by design.)  And AFAIK *every* language except PHP
> and Lua separates sequences from dictionaries.  Typed arrays will not ful=
l
> resolve the seq vs dict problem, which is arguably PHP's original sin.  A=
nd
> there's a lot of weird issues to resolve around what the syntax could eve=
n
> be, since PHP has untyped variables.
>
> The custom collection syntax Derick has been working on is a second-best
> alternative to generics, essentially.  It is less ergonomic, no question,
> but can also be implemented without generics, and so is about 5x easier t=
o
> do.  If we could get native generics, then I think everyone involved agre=
es
> building collections off of that -- in essentially the same way as every
> language I mentioned above --- would be preferable to a custom one-off
> syntax.
>
> --Larry Garfield
>

Considering other languages it is worth mentioning that Java and C# have
generics AND typed arrays that act as a typed list/seq so sure it doesn't
solve all problems otherwise these languages wouldn't have both of them.

From my personal experience, a typed list/seq solves most cases where I
need the elements of an array to be strictly instances of a specific type.
What I see typed list/seq like `string[]` has more ergonomics, it can be
used to interact between libraries and application code without creating
intermediate objects, while collection<Dict> proposal always requires
declaring type - this simply multiplies the number of declared types and
create more coupling where it is not needed! Also, most cases I work with
are just fine with using just foreach or array_ family functions.

I believe typed list/seq could also be used to implement custom collection
like:

class Article {
    function __construct(public string $title) {}
}

// collection(Seq) Articles<Article> {
// }

final class Articles {
    public function __construct(protected Article[] $articles =3D []) {}
    public function getIterator(): Traversable {
        return new ArrayIterator($this->articles);
    }
} // or extend any other collection class with just typed list/seq property

This doesn't have to collide with generics in any way, as mentioned before
in the thread these features may exist simultaneously, typed list/seq can
translate in the future to a generic type.
I believe it'd make people's lives easier if we could have this in place
soon.
Don't you agree?

Cheers,
Micha=C5=82 Marcin Brzuchalski

--000000000000d3188d061c284ee6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">pon., 1 lip 2024 o 03:01=C2=A0Larry G=
arfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.co=
m</a>&gt; napisa=C5=82(a):<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On Sun, Jun 30, 2024, at 11:13 AM, Micha=C5=82 Marcin Brzuchalsk=
i wrote:<br>
&gt; Hi Richard,<br>
&gt;<br>
&gt; czw., 27 cze 2024, 22:33 u=C5=BCytkownik Richard Miles <br>
&gt; &lt;richard@miles.systems&gt; napisa=C5=82:<br>
&gt;&gt; <br>
&gt;&gt; &gt; I worked with Joe Watkins to do a proof-of-concept for generi=
c traits.<br>
&gt;&gt; &gt; It&#39;s a bit old since it&#39;s from 2017, but could be a u=
seful starting<br>
&gt;&gt; &gt; point if you are serious about pursuing this idea:<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; <a href=3D"https://github.com/php/php-src/compare/master...mo=
rrisonlevi:php-src:parameterized_traits" rel=3D"noreferrer" target=3D"_blan=
k">https://github.com/php/php-src/compare/master...morrisonlevi:php-src:par=
ameterized_traits</a><br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt; I=E2=80=99m also interested in this; it will help see branches lik=
e these.<br>
&gt;&gt; Did you ever get the POC working? What did you feel like was the b=
iggest hurdle?<br>
&gt;<br>
&gt; There even was an RFC in voting which Joe implemented and it addresses=
 <br>
&gt; nearly what is discussed it this thread <a href=3D"https://wiki.php.ne=
t/rfc/arrayof" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rf=
c/arrayof</a><br>
&gt;<br>
&gt; I must admit that the collection&lt;Dict&gt; proposal is bit too compl=
ex to <br>
&gt; address such tiny but powerfully in my opinion functionality which is =
<br>
&gt; typed array. What Derick showed looks more like generic collection and=
 <br>
&gt; such require declaring it&#39;s type. In my opinion this is way too mu=
sh <br>
&gt; hassle to declare as many collection types as many usages in <br>
&gt; application. Also two collection types with the same collection item <=
br>
&gt; type will not be compatible from type perspective. While typed array <=
br>
&gt; seems much more clear and compatible in all places where typed array i=
s <br>
&gt; needed without declaring separate type for each usage.<br>
&gt;<br>
&gt; If I were to choose between typed-array and collection like Derick <br=
>
&gt; showed a little bit I&#39;d choose typed arrays definitely as a first =
<br>
&gt; feature to be merged into PHP.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Micha=C5=82 Marcin Brzuchalski<br>
<br>
Contextual point: Nearly every other major language at this point that has =
a meaningful standard library has gone with a three-separate-object approac=
h (Seq, Set, Dict, called various things).=C2=A0 At least Python, Javascrip=
t, Rust, Kotlin, and Swift, in my research.=C2=A0 (Go doesn&#39;t, but Go a=
voids having features by design.)=C2=A0 And AFAIK *every* language except P=
HP and Lua separates sequences from dictionaries.=C2=A0 Typed arrays will n=
ot full resolve the seq vs dict problem, which is arguably PHP&#39;s origin=
al sin.=C2=A0 And there&#39;s a lot of weird issues to resolve around what =
the syntax could even be, since PHP has untyped variables.<br>
<br>
The custom collection syntax Derick has been working on is a second-best al=
ternative to generics, essentially.=C2=A0 It is less ergonomic, no question=
, but can also be implemented without generics, and so is about 5x easier t=
o do.=C2=A0 If we could get native generics, then I think everyone involved=
 agrees building collections off of that -- in essentially the same way as =
every language I mentioned above --- would be preferable to a custom one-of=
f syntax.<br>
<br>
--Larry Garfield<br></blockquote><div><br></div><div>Considering other lang=
uages it is worth mentioning that Java and C# have generics AND typed array=
s that act as a typed list/seq so sure it doesn&#39;t solve all problems ot=
herwise these languages wouldn&#39;t have both of them.</div><div><br></div=
><div>From my personal experience, a typed list/seq solves most cases=C2=A0=
where I need the elements of an array to be strictly instances of a specifi=
c type.</div><div>What I see typed list/seq like `string[]` has more ergono=
mics, it can be used to interact between libraries and application code wit=
hout creating intermediate objects, while collection&lt;Dict&gt; proposal a=
lways requires declaring type - this simply multiplies the number of declar=
ed types and create more coupling where it is not needed! Also, most cases =
I work with are just fine with using just foreach or array_ family function=
s.</div><div><br></div><div>I believe typed list/seq could also be used to =
implement custom collection like:</div><div><br></div><div>class Article {<=
br>=C2=A0 =C2=A0 function __construct(public string $title) {}<br>}<br><br>=
// collection(Seq) Articles&lt;Article&gt; {<br>// }<br></div><div><br></di=
v><div>final class Articles {</div><div>=C2=A0 =C2=A0 public function __con=
struct(protected Article[] $articles =3D []) {}</div><div>=C2=A0 =C2=A0 pub=
lic function getIterator(): Traversable {</div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
return new ArrayIterator($this-&gt;articles);<br>=C2=A0 =C2=A0 }<div>} // o=
r extend any other collection class with just typed list/seq property</div>=
<div><br></div><div>This doesn&#39;t have to collide with generics in any w=
ay, as mentioned before in the thread these features may exist simultaneous=
ly, typed list/seq can translate in the future to a generic type.</div><div=
>I believe it&#39;d make people&#39;s lives easier if we could have this in=
 place soon.</div><div>Don&#39;t you agree?</div><div><br></div><div>Cheers=
,</div><div>Micha=C5=82 Marcin Brzuchalski</div></div></div>

--000000000000d3188d061c284ee6--