Re: function autoloading v4 RFC

On Thu, Sep 5, 2024, at 21:03, Jakob Givoni wrote: > > > On Wed, Sep 4, 2024 at 9:18 PM Rob Landers <rob@bottled.codes> wrote: >> __ >> On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote: >>> >>>> 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. > > I see that under "Future scope" you put: >> Potentially, constants and stream wrappers can be added in a similar fashion. > Trying to figure out if you are referring to the possibility of autoloading stream wrappers and > constants? Is that something there's a need/desire for? Hey Jakob, I'm replying this in a separate thread because it is more or less 'meta' than my other reply. There have been discussions about this off-and-on for awhile, but the gist is that there are people that would find it useful. For example, in my experimental "time" library there is a SECOND and MINUTE constant that must be required if you have the library, even if your code execution path never uses them. So, I think there might be some usefulness to constant autoloading. Further, there are some great async libraries that use stream wrappers to hijack/use file_get_contents and friends in an async way, so having autoloading there may also be useful. That being said, I wanted to constrain the scope initially as this appeared to be a hot topic (autoloading functions) every time it came up. Thus I was preparing myself for a long and drawn-out discussion and kept the scope minimal. I hope that helps explain why it is under future scope. — Rob