Re: Overriding GMP objects

On Wednesday, 26 June 2024 at 18:24, Rob Landers <rob@bottled.codes> wrote: > Hello internals, > > I've had this little library for a while (https://github.com/withinboredom/time), mostly > as a place to experiment with the quirks of PHP and take it in weird places. Anyway, I've been > experimenting with "strongly typed time" in attributes for a while now. At this point, > it's a little weird but doable to use something like this: > > #[MyAttribute(units: StandardSecond, amount: 5)] > > ... which is less than ideal. What I would really like is this: > > #[MyAttribute(5 * StandardSecond)] > > PHP doesn't support operator overloading, which, from the last RFC attempt, probably > won't for quite a long time. Thus, I started experimenting with extending the \GMP class, which > is perfectly allowed since it isn't final. For those that don't know, GMP implements > operator overloading such that a GMP number times an int results in a new GMP number. > > Surprisingly, I can get this to work, but I end up with a GMP number -- with the right value -- > but not the right type. Hence this email. In essence, I am attempting to "back-door" my > way into having operator overloading. > > I would like to add static protected methods to the GMP class that are called for operations. > In the event all objects are base-GMP objects, no behavior will change. No, GMP not being final was a mistake, mainly due to it the first conversion from resources to opaque objects. I was intending on making the class final via an RFC because no one extends it, as it is pointless (checked also on private codebases via Exakat). AND This whole back-door idea was explicitly shut down in the BCNumber RFC that got accepted for 8.4. I do not want a random extension being abused for this purpose. If you want to add operator overloading by that way you can do something very simple, which is create a new extension which has a class with all the relevant method that overloads the do_operator to call the relevant methods on the class. You've got your back-door without poluting the problem space of an unrelated extension which is not even required to be installed. > - should we revisit operator overloading instead of me hacking my way into it? Yes. > - should we revisit "constant expressions" in attributes I do not see how this relates to the problem space if we have the above or you use a new dedicated extension for this. Best regards, Gina P. Banyard