Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124032
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
In-Reply-To: <1E8F63D8-68AA-4D9F-A9DB-EF989F7E6D17@rwec.co.uk>
Date: Sat, 29 Jun 2024 09:07:34 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <09411A26-A174-47AF-9853-F10DF3F12940@newclarity.net>
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <0acedb8e-34be-4348-907b-4075cf7641fd@app.fastmail.com>
 <CAMrTa2Hhk31hgbr_fR7YAb94YPN030oTkvV5UD_ynRBM664QfQ@mail.gmail.com>
 <9c20b078-f82a-47fe-af23-2f3cdd233079@app.fastmail.com>
 <CAEUnE0fTwbc8LabwaNUxp9=vWCnes0E+E_zM+a_Ojera=jQSKg@mail.gmail.com>
 <A8486FCE-2788-47DF-9778-2872A3D32FC4@newclarity.net>
 <50529C6A-42BB-4D49-B720-FE1847577484@rwec.co.uk>
 <97EA49E2-43A9-42D2-B493-A6B66CC54914@edison.tech>
 <1E8F63D8-68AA-4D9F-A9DB-EF989F7E6D17@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 29, 2024, at 8:27 AM, Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk> wrote:
> On 29 June 2024 11:56:43 BST, Mike Schinkel <mike@newclarity.net> =
wrote:
>=20
>> That list is just package-specific, nothing about syntax, data types, =
control structures, package management, etc. etc.
>=20
> It includes fundamental design decisions like "what does a class name =
look like", and "how are classes identified across boundaries". If names =
aren't universal, what does ::class return? How does resolution work in =
a DI container? Etc etc etc.=20
>=20
> I'm sure Go has answers to all those questions, but so does PHP, and =
I've not seen any convincing argument why we should throw it all away =
and start again.

That comment sounds like you think that I am saying to do what Go does =
for PHP.  That is not what I was saying.

Instead, I am saying "let us look at these aspects of Go for inspiration =
for features that would be beneficial for PHP."

Anyway, I have started a repo to put thoughts down, so continuing this =
discussion is probably premature before I have something more to =
show/discuss.

>>> Rather than looking at languages which have done things completely =
differently,=20
>>=20
>> There is nothing "completely" different about JavaScript, or Go for =
that matter.    All three of JS, Go, and PHP are descendants of C.
>=20
> You have misread what I wrote. I didn't say *the languages* are =
different, I said *the decisions they have made around namespaces and =
packages* are different.
>=20
> There is no "genetic fallacy" or "gatekeeping" involved, I'm saying it =
will be easier to apply a design that shares some characteristics with =
what we have, than to rewrite the language to fit a design which shares =
none.

Fair point. =20

But let us not dismiss ideas that come from a language that you admitted =
are not that familiar with =E2=80=94 just because it comes from that =
other language =E2=80=94 before fully understanding what is being =
proposed.

> The descriptions of the *design of packages* in JS and Go make me =
think they don't have enough in common with PHP to be easy to apply, so =
I'm suggesting we look at other designs.

And I am suggesting that maybe those designs will benefit PHP more than =
thinking inside the box.

That said, I will applaud you bringing specific concepts to the table =
from any other languages.

-Mike

P.S.  What I am working on at the moment =E2=80=94 after one tweak of =
that list of ten things to get inspired about from Go =E2=80=94 is a lot =
more like PHP than you are probably currently envisioning and can =
possibly be implemented with much less of a production than anyone is =
likely assuming.=