On Thu, Jun 27, 2024 at 2:14 PM Rob Landers <[email protected]> wrote:
> On Thu, Jun 27, 2024, at 05:39, Gina P. Banyard wrote:
>
> 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.
>
>
> Oops, I extended it :p (pun not intended)
>
> In all seriousness, I actually find it a little weird but the weirdness
> can be tucked away (check the readme file) for an ergonomic usage. It still
> needs fleshing out, but for any kind of units library, it is an amazing
> accident. I’d argue for keeping it or even embracing it.
>
> — Rob
>
I don't, that's why I pushed to include operator overloads. In fact, one of
the libraries I was going to build (and have already partially built) was a
units library that automatically handled unit conversions, multiplications,
etc. by keeping track of everything in SI base units and providing
different value classes for different combinations of SI base units.
If you want to look at how I did that, I can email you the repo for that
code directly, though I haven't touched it in a LONG time because it's
mostly useless without operator overloads.
Jordan