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?
>
> 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'
Hey Jakob,
Thank you for sharing your thoughts on this. I see where you’re coming from
regarding enums and named parameters as a more modern approach, and I
appreciate your suggestion to consider them.
For the current RFC, I leaned towards using binary flags because they provide a
level of consistency with existing PHP functions. There are also some technical
challenges with using enums here, especially since enums seem incompatible with
SPL due to its recursive dependency. This is something I hope we can address in
the future, potentially through Gina's RFC.
I think named parameters could be a good middle ground and might make the
function calls clearer. If you don't mind me asking, what do you have against
binary flags?
I also understand your concern about making adjustments to the API twice and
how it might have to change again if Gina's RFC passes. My thinking was that by
moving forward with this proposal, we at least make some progress on function
autoloading, which has been debated, off-and-on, for a long time.
I'm not opposed to holding off on merging the implementation if it makes sense
to wait and see how Gina's proposal develops, but I also don't want to risk
withdrawing my RFC and Gina's not passing for unrelated reasons; I hope that
makes sense.
— Rob
