On Thu, Sep 5, 2024 at 10:58 PM Rob Landers <rob@bottled.codes> wrote:
> 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. > Ok, I had not thought about it, but it makes sense. Thanks for the explanation! > > 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 >
