On Wed, May 7, 2025 at 3:24 PM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> > Problem number 2 is what you seem to be trying to address. > The main thing, yes. This solution incidentally solves class privacy issues several unrelated and failed RFC's have addressed, including Nested Classes which is currently not doing so well in its vote. > > NPM is notorious for creating a giant directory of tiny modules, because > that's what the language design encourages. > > Indeed. Definitely the bathwater to be thrown out. > > That's not how PHP works, and it never will be. In PHP (and other > languages like Java, and C#), declarations have a single fully-qualified > name. If you want two different versions of the same library, you will > need to find a way to make their declarations use different > fully-qualified names. > Other libraries have the means to import into a namespace because their namespaces aren't just a quick and dirty string replacement. I've even proposed such a long, long time ago - allowing namespace to be the second argument of require, only to have that shot down as "require isn't a function." or some such. > The main exception, as you have pointed out, is plugin architectures > like WordPress, where the plugin might want to "privately" use some > library without impacting the host application and other plugins. It's not just WordPress. Drupal and other CMS's have extensions, but their reliance on composer means abandoned plugins that need an old library can block updating the whole system. The larger and more popular the application is the more likely this becomes. And like it or not WordPress haters on the board, for as much as WordPress sucks (and I will agree, it sucks hard) it still have a 50% - 80% market share of PHP websites depending on who you ask. A lot of this stems from the fact that end users just want their site to work - they don't give a rat's ass about dependencies and the like - and needing to drop a plugin to upgrade a site will put a bad taste in their mouth at best. > For > those, userland solutions already exist - a random search turned up this > one, which lists some alternatives: > https://github.com/BrianHenryIE/strauss?tab=readme-ov-file#alternatives > > I've seen Strauss in action. It's called monkey-typing. Other languages support this sort of monkey typing to some degree - PHP can only do it by doing an expensive and error prone programmatic keyword search of the source files and transforming them. The end result has to be shipped with the module, severing its dependencies from getting security updates. I *do* think PHP would benefit from some native concept of "module" for > other reasons, e.g. marking internal components, optimising across > multiple files. I *do not* think that ES/JS/TS is a suitable model to > look at, because it is starting from a fundamentally different concept > of what a declaration is. > So what do you suggest then? Go's model? Rusts? Gradle or Maven from Java? Shooting down stuff is trivial, finding solutions is the real work. > >
