Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127284
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 04 May 2025 16:18:56 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <9cbbe803-5fd1-4011-b42e-033d4ede3fe9@app.fastmail.com>
In-Reply-To: 
 <CAEUnE0c88jp9LeoHnngqvU+XjL_fpwPcfKi1g7hg6k6PBN6KCQ@mail.gmail.com>
References: 
 <CAEUnE0c88jp9LeoHnngqvU+XjL_fpwPcfKi1g7hg6k6PBN6KCQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Modules, again.
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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