Overriding GMP objects

__

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.

How is the library supposed to do that in the absence of operator handler functions that can be overridden, or at least called when an operator is encountered?

Jordan

That’s what this email is about: adding those functions to the base GMP class as static protected methods.

A time class would look something like:

static protected add(GMP $left, GMP $right) {
if($left instanceof self && $right instanceof self) return new self(parent::add($left, $right));
throw new LogicException('can only add time to time');
}

— Rob

Hi Rob,

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