Re: [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> 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: > >> 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.