> On Jun 29, 2024, at 8:27 AM, Rowan Tommins [IMSoP] <[email protected]> wrote:
> On 29 June 2024 11:56:43 BST, Mike Schinkel <[email protected]> wrote:
>
>> That list is just package-specific, nothing about syntax, data types, control structures,
>> package management, etc. etc.
>
> 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.
>
> 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,
>>
>> There is nothing "completely" different about JavaScript, or Go for that matter.
>> All three of JS, Go, and PHP are descendants of C.
>
> 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.
>
> 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.
But let us not dismiss ideas that come from a language that you admitted are not that familiar with
— just because it comes from that other language — 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 — after one tweak of that list of ten things to get
inspired about from Go — 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.