> On 3 Jul 2024, at 23:51, Matthew Weier O'Phinney <[email protected]> wrote:
>
>
>
> On Wed, Jul 3, 2024 at 9:50 AM Stephen Reay <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On 3 Jul 2024, at 21:07, Vincent de Lau <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> From: Stephen Reay <[email protected] <mailto:[email protected]>>
>>> Sent: Wednesday, July 3, 2024 1:17 PM
>>>
>>>> On 1 Jul 2024, at 23:33, Mike Schinkel <mailto:[email protected] <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.
>>>
>>
>> If you choose to be offended by my opinion, I can't really help that.
>
> No, but you also don't need to air your personal grievances on the mailing list. If you
> don't like what FIG or any other entity in the PHP ecosystem is doing, this is NOT the place to
> air that grievance. Internals is for discussing changes to the runtime. Calling out entities like
> this here is bound to alienate folks who want to work on the engine, and who are also parts of those
> groups.
>
I'm glad we're in agreement that this list is about the runtime and not about composer or
FIG. I look forward to seeing a response from you as vivid as this one, the next time someone
responds to a discussion about something like function autoloading with "X isn't really a
problem because composer".
> It also doesn't help your argument when you're stating things that are flat out wrong
> as facts. You can absolutely use spl_autoload() alongside the PSR recommendations or Composer; see
> more below
Please re-read what I wrote, before making ironic statements about 'facts'. I never said
you can't use them "along side" each other. I said that the PSR's are incapable
of using the built-in functionality provided by spl_autoload. That is: you can't adhere to
either PSR using the builtin autoloader alone. That you can use them along-side each other is
*unrelated* to spl_autoload, it's a function of the stack created by
spl_autoload_register.
> .
>>
>>> 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.
>>>
>>
>> It's less highly opinionated than either PSR, but that's my whole point:
>> it's *someone else's opinion*, hence it's opposed by FIG.
>
> That's a gross mischaracterization.
>
> In point of fact, most frameworks that joined FIG in the beginning were leveraging
> spl_autoload_register(), which provides a _stack_ of autoloaders that each provide their own logic
> for how to map classes to where on the filesystem they live. spl_autoload_register() came after
> spl_autoload(), and was introduced *to add flexibility* to the language, as spl_autoload is
> proscriptive and only allows a single approach to autoloading, and it wasn't even one that was
> widely used at the time it was introduced. It's not about _opinions_, it's about
> recognizing that different approaches might have merit. (Some might give better performance, some
> might allow pulling items out of a phar or tarball, etc.)
>
spl_autoload, spl_autoload_register, and spl_autoload_extensions were all added in php5.1 (compare
https://3v4l.org/H60EG#v5.0.5 vs https://3v4l.org/H60EG#v5.1.0). Maybe you're thinking
of __autoload, which had no default implementation before spl_autoload was added.
> The configurable part for autoloading in the language is spl_autoload_register(), full stop.
spl_autoload is (and has been since inception) configurable via spl_autoload_extensions, and via the
standard include path.