> On Jun 29, 2024, at 03:11, Rob Landers <rob@bottled.codes> wrote: > > On Sat, Jun 29, 2024, at 03:05, Ben Ramsey wrote: >> > On Jun 28, 2024, at 18:53, Gina P. Banyard <intern...@gpb.moe> wrote: >> > >> > Hello internals, >> > >> > I would like to present an RFC to make the GMP class final: >> > https://wiki.php.net/rfc/gmp-final >> > >> > This is short and to the point, and I intend to open voting for this after >> > the mandatory discussion period of 2 weeks has happened, i.e. on the 13th >> > of July 2024. >> > >> >> >> Is this RFC intended to compete with the “Operator Overrides -- Lite >> Edition” RFC, which explicitly allows extending \GMP? >> >> https://wiki.php.net/rfc/operator_overrides_lite >> >> (It also has a secondary vote to “disallow extending the \GMP class if this >> RFC fails.” >> > > Yes, this is interesting. In any case, I feel like it should be final as it > is currently and doesn't affect my RFC. If this RFC passes, it only changes a > bit of the language in my RFC and removes a secondary vote. > > In any case, I haven't seen any emails of people flipping tables (like some > proposals out there) to my RFC announcement, so I suspect it isn't a terrible > idea and might actually have some merit; but I'm not going to get my hopes > up. I rather suspect people are just ignoring it and will vote "decline" > out-of-hand without thinking about it.
If this RFC passes, it would invalidate the first voting choice in the Operator Overrides RFC, which is: > Allow extending the \GMP class and use a form of operator overloading If this RFC passes to make the \GMP class final, and your RFC passes to allow extending the \GMP class, then I think we’re in a sort of weird limbo state. That would mean that different groups of voters participated in voting for each RFC, resulting in competing desires within the community. We should probably combine these RFCs to avoid confusion and a conflicting state like I’ve described here. Cheers, Ben
