> On Jun 29, 2024, at 8:27 AM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > On 29 June 2024 11:56:43 BST, Mike Schinkel <m...@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.
