Re: Modules, again.

> On 5 May 2025, at 04:18, Larry Garfield <larry@garfieldtech.com> wrote: > > On Sun, May 4, 2025, at 2:34 AM, Michael Morris wrote: >> It's been 9 months. Been researching, working on other projects, >> mulling over >> points raised the last time I brought this up. And at the moment I >> don't think >> PHP 8.5 is in its final weeks so this isn't a distraction for that. >> The >> previous discussion got seriously, seriously derailed and I got lost >> even though >> I started it. I'm not going to ask anyone to dig into the archives, >> let's just >> start afresh. > > This proposal requires: > > 1. Every module author to change their coding structure > 2. Every consumer of a package to change their coding structure > 3. Devs to abandon "it just works" autoloading and explicitly import packages. > 4. Abandoning 16 years of PSR-0/4 file convention in favor of "module = file", which > will almost certainly result in multi-thousand-line files even for clean, well-factored code. > > As I stated in the previous thread, this is a total nonstarter. Python/Javascript style module > definition is simply not compatible with PHP. It may have been had we gone that way in 2005, but we > didn't, and that ship has long since sailed. > > Any module proposal worth considering can require only the first point above. Requiring work > from a package author to module-ify their code is fine, though it shouldn't be onerous. But it > needs to "just work" with the rest of the existing ecosystem. This proposal fails at > that. > > Arnaud and I spent some time last year exploring a different approach to modules that requires > only trivial changes by package authors, and none by consumers: > > > https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md > https://github.com/arnaud-lb/php-src/pull/10 > > In our case, the main target was performance by giving the opcache optimizer a larger chunk of > code to work with, plus the potential for namespace-private symbols. Arnaud was able to make it > mostly work, and there was significant potential performance to be had, but it also ran into some > very complex issues very quickly. (Circular dependencies, modules split across multiple > directories, testing, etc.) We largely haven't gotten back to it as the implementation was > very complex and it wasn't clear if the benefit would be worth it, though I'd still like > to revisit it if possible. > > --Larry Garfield > Just to add my $0.02 as a userland/library developer: I agree with Larry's points - it needs to be transparent for the *consumers*, and it absolutely needs to align with namespaces, without any expectation about how symbols relates to files. I personally think initially the goal should be a more minimal approach that simply introduces the concept of a module/package/whatever-term-you-like as something that exists, with an implicit relationship to a namespace. Future RFC's could build on that - even within the same release cycle - but initially agreeing on a basic way to define "this namespace is also a <insert chosen name for a collection of code>" provides a building block for both language/runtime internal enhancements and external tooling. Cheers Stephen