Re: Overriding GMP objects
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
Thread (11 messages)