On Sat, Jul 6, 2024, at 1:12 AM, Mike Schinkel wrote:
> <epiphany>
>
> Reading this however caused me to ponder things certain people has said
> recently — and many people have said for years on this list — and I
> think I am recognizing something that I have always known but never put
> the pieces together before.
>
> Many (most?) people on PHP Internals view WordPress coding standards as
> bad and some even view addressing WordPress developers needs as bad for
> PHP. And in general I concur that those people are reasonably justified
> in their belief WordPress' coding standards are not the standards that
> PHP developer who want to do professional level software engineering
> should aspire.
>
> And since many (most?)* *PHP Internals members generally do not
> experience the issues that WordPress developers have they do not
> recognize that they are issues; IOW, *"out of sight, out of mind." *
>
> I also think some list members tend to dismiss WordPress developers
> pains as unimportant and/or think that addressing those pains have will
> harm* *PHP.
>
> (BTW, I recently had a dialog off-list with someone who wrote in an
> email that *"Wordpress is an exception, but nobody these days treats
> WordPress as a valid example to do anything. It is an ancient piece of
> legacy code that has no bearing on modern situation and it's their
> problem to deal with." *So I am not just erecting a straw man here.)
>
> But I think what most may not consciously recognize is that* WordPress
> is a different type of web app* than an app build using Symfony or
> Laravel and deployed by its developers, or by some other professional
> developer.
>
> WordPress differs from the apps many *(most?)* developers on PHP
> Internals work with in the following way:
>
> WordPress = *User-managed app*
> Most = *Developer-managed apps*
>
> In a* Developer-Managed app* developers choose which 3rd party
> functionality will be incorporated into their sites whereas with a
> *User-managed app* users choose which 3rd party functionality will be
> incorporated into their site. And that is the KEY difference.
>
> So I am wondering if we can get people on this PHP Internals list who
> dismiss the needs of WordPress developer BECAUSE it is WordPress to
> recognize that User-Managed apps ARE a class of PHP applications have
> needs that **deserve** to be addressed?
> *
> *
> Two (2)* unmet needs of User-Managed apps *that *"standard" *PHP
> currently does not address come to mind:
>
> User-managed apps needs to be able to handle both:
> *
> *
> 1. *User-added add-ons* *("plugins" in WordPress, "modules" in Drupal)
> *that have conflicting dependencies, and
>
> 2. *Add-on directory structures *that do not follow a PSR-4 directory hierarchy.
>
> As for #2, even if those apps could rearchitect their existing
> directory structure they cannot realistically be expected to do with
> because of the huge BC issues their users would experience.
>
> And newly created User-managed apps may still find that a PSR-4
> directory structure is not in the best interest of their project or
> their users. To elaborate, PSR-4 generally assumes that ALL code goes
> into ONE hierarchy and that any and all code that will be autoload gets
> placed in that hierarchy.
>
> But with add-ons it makes a lot more sense to have the entire add-on
> contained in its own add-on directory. This is exactly where PSR-4
> breaks down with respect to User-managed apps.
>
> Sure, you can have multiple PSR-4 autoloader root directories, but that
> does not scale well to websites with a large number of add-ons as many
> WordPress sites I worked on used. Some had over 100 plugins. With a
> hierarchy of autoloader maps that Michael Morris is proposing WordPress
> could collect up all the maps and create one map every time a plugin is
> added, updated or deleted.
>
> </epiphany>
I am going to jump in here on this point specifically, because it seems to be a mix of genuinely
insightful observation (though not unique) and uninformed FUD.
Some context: I haven't seriously used Wordpress in, ever. However, I was a Drupal lead
developer for many years, and wrote, among other things, Drupal's DBAL, Drupal's first
autoloader, Drupal's PSR-3 implementation, was involved in Drupal's file organization
guidelines for Drupal 8+ (when Drupal adopted a PSR-0/4 autoloader), and led the Drupal 8
"Modernize all the things" effort. So I do have some non-trivial experience in this area.
First, you're correct that there is an architectural difference between "projects that
assume the owner has CLI access" and those that do not. You are also correct that most of the
Internals crowd comes from the former.
However, I don't think it's fair to say that's why Internals folks
"dismiss" Wordpress generally. We dismiss Wordpress generally because
1. WP actively harms the PHP community by encouraging the use of ancient PHP versions with known
security issues.
2. WP's code base actively avoids using what have been considered known best-practices (in
either type of application) for 15 years.
3. WP's core team actively avoids being involved in Internals to collaborate on how to make the
language better for them. In fact, they've made it very clear that PHP is a legacy
implementation detail and Node/client-side JS is where their focus is. The only WP-affiliated
person I can even think of that has been a semi-regular Internals contributor is Juliette (whose
participation I very much welcome).
That said, it was recently pointed out to me that Automattic is the top contributor to the PHP
Foundation (https://opencollective.com/phpfoundation), which is very much appreciated and nothing to
sneeze at.
And yes, I fully agree that any module/package/thing needs to take into account the needs of both
types of projects. As Rowan has repeated, that means keeping the impact of any changes minimal, so
that the Composer ecosystem and WP ecosystem can TYPO3 ecosystem can build their own tooling on top
of it.
You'll note I did not list Drupal there. That's because modern Drupal is composer-based,
and has been for many years. I was the one that pushed hard for adopting Composer, its autoloader,
and PSR-4 for Drupal 8 in the first place. While much of the transition happened after I left the
project, the groundwork is over a decade old. Composer is the preferred way to use Drupal, and to
install Drupal modules.
So the line is not as hard between those two models as you might think.
> PSR-4 generally assumes that ALL code goes
> into ONE hierarchy and that any and all code that will be autoload gets
> placed in that hierarchy.
This is flatly untrue, and belies a considerable ignorance about how PSR-4 and Composer work.
PHP supports multiple autoloader callbacks, and has for over 15 years. You absolutely can register
multiple if you'd like, using whatever logic you like. PHP will call each one in turn until the
class is loaded.
All PSR-4 does is specify a directory structure that makes a common autoloader stupidly simple to
write. It's just a few lines long. But you can already do any logic you like for an
autoloader. PHP doesn't care.
However, nothing precludes you from registering multiple autoloaders, all using PSR-4, all using a
different path root. That has been trivially simple to do since 2009. (OK, it was PSR-0 at the
time, but the implications here are the same.) So your statement above about "all code goes
into one hierarchy" is simply flat out false.
Of course, as you note, registering lots of separate autoloaders has a performance impact. That is
true. Which is why I don't think anyone actually does that.
Composer, for instance, registers a single autoloader only. That autoloader internally tracks many
dozens of PSR-4 roots (one for each package, sometimes two per package), as well as files that will
get force-loaded when the autoloader is registered, plus generated classmaps.
Using class maps, you can put a hundred classes in one file and composer can handle that *today*.
That has always been possible. That no one does so is a sign that there's little reason to do
so in most cases.
In fact, if you use an optimized/dumped autoloader, then Composer simply builds an internal giant
lookup table of what class maps to what file. PSR-4 is then *completely irrelevant* at runtime.
It's already one giant O(1) lookup map. That can be done *today*. That *is* done today.
But what about systems like Drupal, that don't put code in /vendor/? Drupal ties
directly into Composer via its API,and has done so for a decade. Drupal, a "user-managed
application" as you describe it, has Composer baked in at a core level.
It looks like the integration has evolved considerably since I was last involved, but have a look
at:
https://git.drupalcode.org/project/drupal/-/tree/11.x/composer
As of when I last looked at it (around 2016 or so), Drupal registers its module code roots with
Composer directly, and then Composer takes over from there and integrates Drupal's code into
its own indexes. There is still only one single autoloader registered with PHP. This is entirely
fine.
I would encourage you to do your research before speaking pseudo-authoritatively on this topic, as
you clearly are mis-stating both the problem and the tools involved today.
What Drupal does not do is address the "different dependency version" question. And
neither does Wordpress. Or TYPO3. Or any other project. Because that's a core PHP
limitation.
In Python, every module is really just an object with a big dictionary of the functions/classes it
has. When you "import" a symbol from another module, the engine is doing little more than
$this['foo'] &= $that['foo']. That's a core part of how
the language works. (I'm not sure of Javascript's details, but I suspect from using it
that it's similar.)
PHP works very very differently. PHP has a single global list of symbols. (Well, two, for classes
and functions.) Namespaces are just syntax sugar over very-long-names, nothing more. There is no
"local symbol table," so having different local symbol tables point to different code
blocks using the same name is not even conceivable.
If you want to change that, and give PHP multiple local symbol tables, then autoloading... is
utterly irrelevant. The question there is "how can we introduce local symbol tables in the
engine without requiring 10 million developers to rewrite the file header of 1 billion PHP files
across the world?" Honestly, I'm not convinced its even possible. Someone with more
engine knowledge than I could be able to find away, maybe, but I am skeptical. If it's even
possible, I suspect it would be an absurdly large amount of work and necessarily include many hard
BC breaks.
If you'd like to prove me wrong, go for it. But that's the problem to address. Debating
file paths is about four steps down the line before it's even relevant. And even then... if
you can't make a PSR-4-organized package (of which there are several hundred thousand) slot
into that new model comfortably with zero effort on the part of the package author, it's
doomed.
So please, spare us the ill-informed descriptions of how you think autoloaders work, when you have
demonstrated you do not know how they work.
Spare us the litany of complaints about PSR-4 when you have demonstrated you don't know what
PSR-4 says.
Spare us the gnashing of teeth about how hard it is to use a Wordpress plugin that hasn't been
updated in 10 years with a modern plugin because the former is still using a 10 year old abandoned
version of some library, when that's not PHP's problem, that's a Wordpress
maintenance problem.
If you want to move this effort forward, here's your todo list:
1. Do some research in the engine to determine if local symbol tables are even possible without
rewriting the engine.
2. Work through the highly complex logic of handling three layer overlapping transitive dependencies
in a diamond pattern with conflicting version requirements.
3. Investigate the performance impact of maintaining multiple versions of the same code in memory at
once, when the order they get loaded will vary by request.
4. Think through how you'd support *both* composer-based and "user managed"
applications with such a model, especially projects that are already architecturally a decade out of
date (like Wordpress).
When you have a proven that it's even possible to have multiple local symbol tables, we can
talk. Until then, please spare us.
--Larry Garfield