Hi Rob,
On Thu, Sep 5, 2024 at 10:45 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?
>
> 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?
>
Sure! I've always just intuitively disliked them, but here's an attempt at
rationalizing my distaste:
- It's not intuitive and easy to remember. If you are a casual user of
functions accepting bitmasks, you may remember that you can pass several
flags, but what is the syntax again? Say I want to pass FLAG_1 AND FLAG_2,
so I use the AND operator, right? That would be the most intuitive
answer... But no, it's OR - and how do we write OR in php? Using double
pipe ||, right? Ah, no for bitwise operations it's a single pipe |. Not to
mention that sometimes you need to use the exclusive or the not operator to
achieve your goal. The error_reporting function is another famous example
that needs its own bitmask calculator page! It's not a great user
experience and can easily lead to subtle bugs...
- There's no standard way to document them. F.ex. see the documentation for
json_encode. The function API just says it's an integer. You have to look
further to understand that it's actually a "bitmask" - which is not a
native type in PHP. And you have to go to another page about bitwise
operators to understand how to compose the flags. Your IDE will most
probably not help you the least, the way it would if it was an enum or a
named boolean parameter.
- Using a bitmask parameter seems "lazy" on part of the implementer (no
offense intended!), putting all the work of understanding the flags and how
to compose them on the end-user.
That being said, if the PHP community is generally enthusiastic about
bitmasks, it's not a deal breaker for me :-)
>
> 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.
>
Function autoloading is much needed, thank you for working on this!
>
> 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.
>
Your proposed PHP version is 8.5 or later, maybe there's still time to see
how it unfolds?
>
> — Rob
>
>
>
