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?
In any case, it seems less than ideal to introduce a change to existing
functions now only to change them again after Gina's RFC.
Which means we'll be locked into binary flags even if enums (not even sure
what you have against their use in this case) will be possible later.
I also mentioned named parameters as an alternative, any thoughts on that?
F.ex. changing one of your examples to:
spl_autoload_call('func', function: true, class: true); // Calls both
autoloaders with the name 'func'
Best,
Jakob
