Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124136
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <1b4acf29-968a-4731-9d64-a1945396df3c@app.fastmail.com>
In-Reply-To: 
 <CABdc3Wph2TevxQrG6CWurj0svWAvX=mQ0T2R3yxCgQkr2wmdSA@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>
 <4996ae09-e5eb-4a8b-90e2-7461805c4cb7@app.fastmail.com>
 <CABdc3Wph2TevxQrG6CWurj0svWAvX=mQ0T2R3yxCgQkr2wmdSA@mail.gmail.com>
Date: Mon, 01 Jul 2024 12:37:14 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jul 1, 2024, at 4:48 AM, Micha=C5=82 Marcin Brzuchalski wrote:
> pon., 1 lip 2024 o 03:01 Larry Garfield <larry@garfieldtech.com> napis=
a=C5=82(a):

>> Contextual point: Nearly every other major language at this point tha=
t has a meaningful standard library has gone with a three-separate-objec=
t approach (Seq, Set, Dict, called various things).  At least Python, Ja=
vascript, Rust, Kotlin, and Swift, in my research.  (Go doesn't, but Go =
avoids having features by design.)  And AFAIK *every* language except PH=
P and Lua separates sequences from dictionaries.  Typed arrays will not =
full resolve the seq vs dict problem, which is arguably PHP's original s=
in.  And there's a lot of weird issues to resolve around what the syntax=
 could even be, since PHP has untyped variables.
>>=20
>> The custom collection syntax Derick has been working on is a second-b=
est alternative to generics, essentially.  It is less ergonomic, no ques=
tion, but can also be implemented without generics, and so is about 5x e=
asier to do.  If we could get native generics, then I think everyone inv=
olved agrees building collections off of that -- in essentially the same=
 way as every language I mentioned above --- would be preferable to a cu=
stom one-off syntax.
>>=20
>> --Larry Garfield
>
> Considering other languages it is worth mentioning that Java and C#=20
> have generics AND typed arrays that act as a typed list/seq so sure it=20
> doesn't solve all problems otherwise these languages wouldn't have bot=
h=20
> of them.

I believe in those languages Array came first, and then the collections =
were added later when they determined that Array was insufficient and to=
o low-level.  (I'm not an expert on the history of either language, but =
that's my understanding from reading their documentation.)  Using the co=
llections is the preferred approach now for most applications.

> From my personal experience, a typed list/seq solves most cases where =
I=20
> need the elements of an array to be strictly instances of a specific=20
> type.
> What I see typed list/seq like `string[]` has more ergonomics, it can=20
> be used to interact between libraries and application code without=20
> creating intermediate objects, while collection<Dict> proposal always=20
> requires declaring type - this simply multiplies the number of declare=
d=20
> types and create more coupling where it is not needed! Also, most case=
s=20
> I work with are just fine with using just foreach or array_ family=20
> functions.

Yes, the need to create the monomorphized object yourself is a downside =
of the dedicated collections syntax.  No question.  The trade-off is tha=
t it's vastly easier to implement than either full generics or typed arr=
ays.  We haven't fully developed it yet as there's still experimentation=
 going on (by people with far more engine knowledge than me) to see if w=
e can have our cake and eat it too.

> This doesn't have to collide with generics in any way, as mentioned=20
> before in the thread these features may exist simultaneously, typed=20
> 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=20
> place soon.
> Don't you agree?
>
> Cheers,
> Micha=C5=82 Marcin Brzuchalski

1. I think you are vastly under-estimating the level of effort for makin=
g typed arrays, and making them performant.  Arnaud has been exploring t=
hat, and it's far from trivial.  "Have this in place soon" hand-waves ov=
er an awful lot of complexity.

2. You're correct that typed arrays and generics could coexist in the la=
nguage, if both could be implemented.  But that is also a lot of work, w=
ith overlapping problem spaces.

3. The core failing of typed arrays is that they still don't guarantee a=
 sequence; everything is still a string|int key dictionary with no suppo=
rt for object keys, and PHP's screwy array-specific type casting.  Frank=
ly, people who don't see the challenges here have not tried to write arr=
ay-handling libraries. :-)  (Crell/fp taught me all kinds of things abou=
t how broken arrays are, due to their fundamental unpredictability.)

--Larry Garfield