Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113554
Message-ID: <BBFADB95-8AAF-4BDD-A433-929EDC6B99E9@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5AB43497-3E70-4BDA-9EDF-44C8F24089AE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 15 Mar 2021 22:57:43 -0400
In-Reply-To: <604f9c5c.1c69fb81.3093.e541SMTPIN_ADDED_MISSING@mx.google.com>
Cc: internals@lists.php.net
To: Mark Randall <marandall@php.net>
References: <604f9c5c.1c69fb81.3093.e541SMTPIN_ADDED_MISSING@mx.google.com>
Subject: Re: [PHP-DEV] [RFC] Autoloader Classmap
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_5AB43497-3E70-4BDA-9EDF-44C8F24089AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Mar 15, 2021, at 1:41 PM, Mark Randall <marandall@php.net> wrote:
>=20
> Hi Internals,
>=20
> I would like to propose the addition of a new mechanism of autoloading =
classes - a classmap that will be consulted prior to checking the =
spl_autoload_register'd callbacks.
>=20
> https://wiki.php.net/rfc/autoload_classmap

Yes, please!  This would be a real treat for those whose use-cases do =
not fit nicely into the PSR-4 standard (like WordPress plugins.)

However, may I discuss some additions?

-----------
1. Sometimes it is inconvenient to set the entire class-map.  For =
example, a WordPress plugin might want to add all of its files to the =
autoloader and let other plugins handle their own needs. =20

While that could be done with your get() and set() functions along with =
an array merge, it would be clearer in userland just to have an add(). =20=


Further, when there are tens of plugins then adding the files for each =
plugin could be a lot of userland array manipulation that I assume could =
be done more efficiently within a core function.

So, I would propose including a third function that would add to the =
current classmap rather than just replace it like set():

autoload_add_classmap(mapping $array): void {}

-----------
2. There has been numerous times when I wanted to monitor when classes =
are loaded. I have been reduced to calling get_declared_classes() before =
require_once() and then call get_declared_classes() again after and =
slice off the difference between the two, which I assume is very costly.=20=


If would be great is the autoloader could call a callable and pass the =
list of classes that were loaded, assuming such as callable exists.

So, I would propose including a third function that would add to the =
current classmap rather than just replace it like set():

autoload_set_classmap_listener(callable $listener): void {}
autoload_get_classmap_listener(): callable {}

This might be tangential to your RFC but if we are updating the =
autoloader already this addition might be trivial.=20

-----------
3. Based upon the above and the existing spl_*() functions I would ask =
it it would not make sense to create an interface called "Loader"  and a =
set of classes to support autoloading instead, and then deprecate the =
spl_*() at some distant point in the future? =20

To provide something to make it easier to consider this approach I =
created a strawman Gist using PHP code to illustrate the idea. It is not =
a complete working example, and likely not fully fleshed out either, but =
it should work as a starting point for discussion:=20

https://gist.github.com/mikeschinkel/2ff8b5f78e88688dbbadb41a762c119f =
<https://gist.github.com/mikeschinkel/2ff8b5f78e88688dbbadb41a762c119f>

Note that using an interface like this would allow developers to create =
their own custom autoloaders as classes and/or we could implement a =
PSR-4 specific autoloader class in the future directly in core that =
could work with this configuration (and maybe even a PSR-1 autoloader in =
core.)

-Mike

P.S. The interface and classes example uses the controversial "PHP" =
namespace, but please let us not fixate on that. Let us instead discuss =
if an interface and set of classes makes sense and if so figure out the =
right namespace afterwards.



--Apple-Mail=_5AB43497-3E70-4BDA-9EDF-44C8F24089AE--