> On 5 May 2025, at 04:18, Larry Garfield <la...@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
