Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127289
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [PHP-DEV] Modules, again.
In-Reply-To: <9cbbe803-5fd1-4011-b42e-033d4ede3fe9@app.fastmail.com>
Date: Mon, 5 May 2025 14:02:16 +0700
Cc: Larry Garfield <larry@garfieldtech.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <CF3146A7-51A5-43E0-824E-1CC5800CBDD4@koalephant.com>
References: <CAEUnE0c88jp9LeoHnngqvU+XjL_fpwPcfKi1g7hg6k6PBN6KCQ@mail.gmail.com>
 <9cbbe803-5fd1-4011-b42e-033d4ede3fe9@app.fastmail.com>
To: php internals <internals@lists.php.net>
From: php-lists@koalephant.com (Stephen Reay)



> On 5 May 2025, at 04:18, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Sun, May 4, 2025, at 2:34 AM, Michael Morris wrote:
>> It's been 9 months. Been researching, working on other projects,=20
>> mulling over=20
>> points raised the last time I brought this up. And at the moment I=20
>> don't think=20
>> PHP 8.5 is in its final weeks so this isn't a distraction for that. =20=

>> The=20
>> previous discussion got seriously, seriously derailed and I got lost=20=

>> even though=20
>> I started it. I'm not going to ask anyone to dig into the archives,=20=

>> let's just=20
>> start afresh.
>=20
> This proposal requires:
>=20
> 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 =
=3D file", which will almost certainly result in multi-thousand-line =
files even for clean, well-factored code.
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
> =
https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md
> https://github.com/arnaud-lb/php-src/pull/10
>=20
> 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.
>=20
> --Larry Garfield
>=20

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=20