On Fri, Jun 28, 2024, at 02:43, Saki Takamachi wrote:
> Hi Rob,
>
> >> On Thu, Jun 27, 2024, at 06:07, Saki Takamachi wrote:
> >>
> >> 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?
> >
> > Ask the class what it wants to be?
> >
> >> - Multiplying the distance class and the speed class should give you the time class.
> >
> > That would depend on the library’s implementation.
> >
> >> - Similarly, multiplying two distance classes together should yield an area class.
> >
> > See above.
> >
> >> - 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.
> >
> > This can be handled via the child class in static methods, per the library specifications.
> >
> >>
> >> These problems cannot be solved without significant complexity. And there is a
> >> possibility that it cannot be resolved in the first place.
> >
> > I very much disagree; there is very little complications in the extension. It’s actually
> > quite simple:
> >
> > If one value is scalar and the other an instance of GMP, for binary ops, ask the GMP class
> > to perform the operation. (This is a one-linish change)
> >
> > If both are GMP instances, in a binary op, ask the left-most one to perform the op. The
> > default GMP implementation will delegate to the right-side if the right side isn’t a base-GMP
> > instance, otherwise, business as usual.
> >
> > And that’s pretty much it, other than defining the base-type ops. From there, you can
> > implement any units library you want, with whatever behavior makes sense — so long as the base
> > representation is a number.
> >
> > If I remember the original operator overloading RFC, this is exactly what was asked for by
> > the people who voted no. In theory, it should pass if brought as an RFC.
> >
> > — Rob
>
> I see.
>
> All of what I wrote are problems that arise when php doesn't provide a way to control them
> in userland.
>
> Your proposal implicitly allows operator overloading in userland.
I wouldn’t go that far. First of all, it would only apply to numerical constructs and operations;
there’s no way to override concatenation (so you can’t make concatenation act like a
dot-product); I’m not considering things like less-than/greater-than or even equals. I’m only
considering mathematical operators, like +, -, /, %, etc. And lastly, there’s no special syntax
like you would expect from proper operator overloads.
If anything, I would consider this operator overloading, lite edition.
>
> So your proposal essentially amounts to allowing operator overloading only for GMP classes.
Yes, this would basically amount to being able to have some typed control over types of numbers
(aka, units) or in simpler words: limited overloading is available for anything that can be backed
by a single numerical value.
>
> If I understand correctly, this discussion is not centered on GMP, but on the topic of limited
> exposure of operator overloading functionality.
It’s centered on GMP because the resource converted to object was left non-final, thus providing a
way to provide a “typed number” to the engine. This actually presents a unique opportunity to
implement a limited form of operator overloading in a way that is strictly opt-in (must have the GMP
extension), useful, and what the detractors wanted on the last RFC (no special syntax, limited
scope, some don’t want it at all — this is opt-in). To me, this seems like exactly what was
asked for.
> I believe this is something that requires some very careful discussion.
I agree and also disagree. We have an already well-thought out and researched, yet declined, RFC on
the matter that can be used for reference. This means there is probably a lot we don’t need to
think too hard on. Then there is the fact that this is in an extension, and not a very common one.
Who knows, maybe having a limited form of operator overloading might convince people that proper
operator overloading would be beneficial.
I’ll go ahead and write up an RFC and then it can be discussed properly.
And fwiw, yes it “feels hacky af” but interestingly, also makes a lot of sense in the
environment we find ourselves in.
— Rob