X-Mailer: iPhone Mail (21D61) From: saki@sakiot.com (Saki Takamachi) --Apple-Mail-FAAD4A38-C714-4153-80FB-48C99EEEF2A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi T= im, Jordan,

On Fri, Apr 5, 2024 at 1:00=E2=80=AFPM Tim D=C3=BCsterhus &= lt;tim@bastelstu.be> wrote:
Hi

On 4/5/24 21:42, Saki Takamachi wrote:
> The only solution I can think of at the moment is to impose the constra= int that
> when computing operator overloading, if the operands are both objects, t= hey must
> be of the exact same class.

Even that would allow for confusing behavior:

class MyNumber extends Number {
private $importantMetadata;

public function doSomething() {
$this->importantMetadata =3D= random_int(1, 100);
}
}

$a =3D new MyNumber(5);
$a->doSomething();
$b =3D new MyNumber(10);
$b->doSomething();

$what =3D $a + $b;

What should be the value of $what->importantMetadata be? The property is <= br> private, so as a user adding two of MyNumber would not even be able to
manually fix it up with the correct value, thus requiring the addition
of a "fixup" method that fixes the internal state of the object,
possibly even lacking the necessary information to properly fix up the
state, because it does not know which operations lead to the state.

Best regards
Tim D=C3=BCsterhus

That is an absurd exa= mple. Why would anyone use inheritance for that class design? If what you ar= e arguing is "if you look at use cases where composition is clearly the corr= ect choice then inheritance causes problems", then I'm not sure what the poi= nt of the discussion is.

Jordan

One of the points Tim makes that actually matter= s is how to get user-defined properties on child classes to be carried over t= o new instances when operators are used to calculate them. (It doesn't reall= y matter that the property is private.)

For example= , suppose you define a tax rate in a child class.

M= y country currently has a mix of 10% and 8% tax rates, so the tax rate prope= rty could contain either 8 or 10.

The question here= is, if add objects with different tax rates, what should the tax rate of th= e resulting object be? It may be that we shouldn't calculate objects with di= fferent tax rates in the first place, but we need to clarify the behavior wh= en we do actually do so.

I've come up with a few op= tions, but none of them are particularly smart. In fact, it's a very bad ide= a...

- If a child class has its own properties, the= ir values =E2=80=8B=E2=80=8Bmust match exactly before any calculations can b= e performed using operators.

- Properties defined in child classes= are always uninitialized when calculated by operators.

- Always a= pply the state of the left operand

Also, as I was t= hinking about this, I realized that $roundMode has the same problem. When ca= lculating with an operator, I needed to consider what should happen if two o= bjects have different $roundModes.

I'll try to thin= k of some more good ideas, but if you have any suggestions, please let me kn= ow.

Regards.

Saki

= --Apple-Mail-FAAD4A38-C714-4153-80FB-48C99EEEF2A4--