On Wed, May 7, 2025, at 3:51 PM, Michael Morris wrote:
>> The main exception, as you have pointed out, is plugin architectures
>> like WordPress, where the plugin might want to "privately" use some
>> library without impacting the host application and other plugins.
>
> It's not just WordPress. Drupal and other CMS's have extensions, but
> their reliance on composer means abandoned plugins that need an old
> library can block updating the whole system. The larger and more
> popular the application is the more likely this becomes. And like it
> or not WordPress haters on the board, for as much as WordPress sucks
> (and I will agree, it sucks hard) it still have a 50% - 80% market
> share of PHP websites depending on who you ask. A lot of this stems
> from the fact that end users just want their site to work - they don't
> give a rat's ass about dependencies and the like - and needing to drop
> a plugin to upgrade a site will put a bad taste in their mouth at best.
If we're going to cite WordPress as a design factor, then we should also recognize that
WordPress has virtually no involvement in PHP Internals, and its version requirement history means
that even if PHP 8.5 were to ship with the perfect multi-version-loading system, it would be around
10 years before WordPress even supported that PHP version. As a practical matter, it's just
not a meaningful factor.
>> I *do* think PHP would benefit from some native concept of "module" for
>> other reasons, e.g. marking internal components, optimising across
>> multiple files. I *do not* think that ES/JS/TS is a suitable model to
>> look at, because it is starting from a fundamentally different concept
>> of what a declaration is.
>
> So what do you suggest then? Go's model? Rusts? Gradle or Maven from
> Java? Shooting down stuff is trivial, finding solutions is the real
> work.
Quoting from my first post in this thread:
> 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.
I don't believe that is a perfect proposal, but it is a different approach that Arnaud's
experimentation shows has the potential for as much as a 20% performance improvement in some
situations. That's nothing to sneeze at. There's still challenges with it, both
implementation and DX, but let's not pretend that aping Python is the only option that exists.
I believe that qualifies as "real work."
--Larry Garfield