Re: function autoloading v4 RFC
| From: | Stephen Reay | Date: | Sun, 18 Aug 2024 09:36:53 +0000 |
| Subject: | Re: function autoloading v4 RFC | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-125042@lists.php.net to get a copy of this message | ||
Hi Rob,
> On 18 Aug 2024, at 04:33, Rob Landers <rob@bottled.codes> wrote:
>
> I wouldn't consider it a BC break, no. But (ironically?), Symfony crashes with this
> change.
I wasn't aware of that specific code before but it's exactly the type of issue I was
talking about earlier.
> Ah, good catch. I've updated this and gone through other relevant functions.
The RFC now says "The spl_autoload function will not be updated.", but that will *also*
break if it isn't updated to at least *account for*, even if it doesn't *use* the second
argument given.
However I'm also curious why you would *specifically* make it *not* support function loading?
The current implementation should work unmodified, once the signature is changed to accept an int as
the second parameter (and move the current 2nd parameter to 3rd), There is nothing "class
specific" in the existing implementation except for a couple of variable names.
I would imagine you also need to update spl_autoload_unregister[1] - it also needs to be able to
identify the type of autoloader it's operating on (because the same autoloader might be defined
for both types).
And lastly I think you'd need to adapt spl_autoload_functions[2] too - perhaps the same as the
others, introduce a parameter
int $type = SPL_AUTOLOAD_CLASS, so existing code works
as-is, otherwise it'd be impossible to know how a given autoloader was registered.
1: https://www.php.net/manual/en/function.spl-autoload-unregister.php
2: https://www.php.net/manual/en/function.spl-autoload-functions.php
Cheers
Stephen