Hi, > On Wednesday, 26 June 2024 at 18:24, Rob Landers <[email protected]> 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
I agree with Gina. Being able to change the class of a computed result of an inherited child class causes several problems. The points raised in the `BCMath\Number` discussion can be summarized as follows. - If it is possible to perform calculations on parent Class and child Class, what should the resulting class be? - Multiplying the distance class and the speed class should give you the time class. - Similarly, multiplying two distance classes together should yield an area class. - If only child classes have a property that should be specified in the constructor, how do you determine the value of this property in the result class? Perhaps it is possible to determine the value of the property, but in that case the commutativity of the computation should be lost. These problems cannot be solved without significant complexity. And there is a possibility that it cannot be resolved in the first place. Regards, Saki
