RE: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

From: Date: Wed, 03 Jul 2024 14:07:28 +0000
Subject: RE: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
From: Stephen Reay <[email protected]> 
Sent: Wednesday, July 3, 2024 1:17 PM

> On 1 Jul 2024, at 23:33, Mike Schinkel <mailto:[email protected]> wrote:
> > Autoloading runs userland code. This means it has the potential conflict between different
> > packages with different autoloaders

> *Can* run userland code. It doesn't *have to*; FYI  spl_autoload
> (https://www.php.net/manual/en/function.spl-autoload.php) has existed since php5.1 and works
> amazingly well. 
>
> That "standards" like psr-whatever can't (read: choose not to) use it says more
> about people and maintaining their little fiefdoms than anything else. 

As a PHP-FIG Core Committee member, I find this characterisation of people involved in the FIG
offensive. My contribution, however big or small, is intended to help the PHP community at large.

Accusing people of 'maintaining their feifdom', especially in the light of a discussion on
autoloading is completely uncalled for. PSR-0 and PSR-4 are the product of (at the time) big
relevant userland projects unifying and codifying a common way of doing things, to avoid conflicts
and improve interoperability. Even though it is a recommendation, I believe it is fair to say it has
become a de-facto standard in the eco-system, like it or not. Still, nobody forces anyone to adhere
to it, not even Composer.

Composer has various autolading strategies [1], PSR-0 and PSR-4 are only two of them. It should be
possible to add a 'package' or 'module' strategy when needed, if needed. When
the module implementation requires significant userland work to make it practical, people will
probably rely on Composer for autoloading, which would probaly also have some requirements on how
the source package is organised. That would probably also trigger an update or addendum to PSR-4, in
collaboration with anyone that wants to.

Likewise, when PHP makes changes to it's autoloading infrastructure I would expect Composer to
leverage those to improve any of the strategies. If for instance a built-in classmap autoloader
would exist, I would expect Composer to use that instead of a userland method.

To come back to spl_autoload: That function pre-dates namespaces and is highly opinionated on how to
organise code. All lower-case filenames, class per-file, files in include_path, full namespace in
path, you name it. If that is what projects wanted at the time, or even now, PSR-0 and the PHP-FIG
would possibly not even exist.

With PHP most of the time not making strong recommendations or even enforcing certain patterns, the
community will seek guidance elsewere. For some topics this leads to competing interpretations,
sometimes they lead to de-facto standards. In the end, nothing and nobody is perfect. PHP,
internals, the FIG, the PSRs, all are made by, or consist of, people trying their best.

--
Vincent de Lau

[1]: https://getcomposer.org/doc/04-schema.md#autoload




Thread (128 messages)

« previous php.internals (#124197) next »