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
