On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote: > > > On Tue, Sep 3, 2024 at 11:49 PM Rob Landers <rob@bottled.codes> wrote: >> 1. I've removed the BC break—the 'type' of the autoloadee will not be passed >> to the autoloader. This can allow someone to use spl_autoload for function >> autoloading if they so desire. > > Unless I'm missing something, the main example in the RFC still shows a > function which expects the $type as the second parameter. Is that intentional?
Nope! Thanks for the heads-up; despite reading it four or five times, I missed this! I've now fixed it. > >> 2. I've removed artificial restrictions on the constants in which all >> functions that take them can accept both at the same time and behave >> appropriately. > > I'm not a big fan passing flags and using binary operations to combine > options into a single parameter. > It works, but it's opaque and old-school. > We have both named parameters and enums now, can't we just use those going > forward, making each option a separate parameter or using enums with 3 cases, > FUNCTION, CLASS or BOTH? Thank you for your opinion, but for cases like this, enums is probably one of the worst choices IMHO. As mentioned towards the end of the RFC, I'd like to add further support for other things, such as constants and stream filters. Further, it appears that enums cannot be used in SPL (at least, I couldn't get it to link) due to SPL having a recursive dependency on itself. This is what Gina's RFC seeks to rectify by breaking autoloading out of SPL. This RFC focuses purely on function autoloading. — Rob
