> On 5 May 2025, at 04:18, Larry Garfield <[email protected]> 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