Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108339
To: <larry@garfieldtech.com>
Cc: "'PHP internals'" <internals@lists.php.net>
Date: Fri, 31 Jan 2020 21:18:07 +0100
Message-ID: <007601d5d873$8d087cc0$a7197640$@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdXYaLHY/k01z6yaTrCFoqYo9xIuqg==
Content-Language: de
Subject: Re: [PHP-DEV] Operator overloading for userspace objects
From: jan.h.boehmer@gmx.de

> I cannot speak to the implementation details.  From a design =
perspective,
I am tentatively positive on operator overloading, with separate method =
for
each operator, BUT, the big question for me is the rules around type
compatibility.
>
> Can you only compare 2 of the same type?  What about subclasses?  Can =
that
differ if a subclass overrides that method?  What happens to =
commutativity
then?  Can you compare based on an interface?

I do not think the types should be restricted at all. For a numeric-like
object like an money value, adding an scalar like an integer or float is
quite useful (e.g. $a + 2.5), for things like vectors this would be not
resolvable (you can only add between vectors, while multiplication with =
an
scalar is valid). In my opinion the object should determine the operands
types and decide if it can handle it or not (and then throwing an
exception). As long as PHP does not allow function overloading with
different types (like C# does), I see no other possibility except =
deciding
on runtime if the type is supported.

For sub classes this is more difficult. I guess in the most use cases
defining a good operation handler in a sub class is sufficient, so maybe =
the
operation handlers could be required to be final. Another possibility =
would
be to let the user handle this situation completely, even if this could =
lead
to undesired behavior.
In my opinion the most elegant solution, would be if an operator handler
could somehow signal that it does not support the type passed (maybe by
returning null, or throwing a special OperandTypeNotSupportedException), =
so
that PHP can try to call the operation handler on the right operand =
(that is
one of the reasons I like passing both operands to a static handler).

> Also, I want to reiterate: Any of these operations MUST be designed to
return a new value, never modify in place.  These operators only make =
sense
on value objects, not service objects, and value objects should be
immutable.

I agree with that. The best solution here would be  an integrated =
support
for immutable value objects (which could become quite complex on its =
own),
but I wonder if it would be sufficient if copies of the objects =
instances
are passed to the operator handler. The user could then change the =
scalar
properties of the object like he wants, without changing the operands
objects.

> Frankly I'd avoid bitwise operators entirely for now.  I'm not even =
sure
how you'd use those...

They could be maybe useful for mathematical objects, that define more =
than
the four basic arithmetic operators (like the cross vs dot on vectors, =
or
tensor product) or four things like length-safe binary number objects. =
Also
I would say they are not used very often in normal PHP, so redefining =
them
as custom operators would be less confusing, then using other operators =
for
that.
But I can understand everyone who dislike the idea of overloading them, =
for
the reason that their used could become too confusing. If there is to be =
an
voting on an RFC, maybe it should be split into a voting on the =
arithmetic
operators/concatenation and a voting on the bitwise operators.

Greetings,
Jan B=F6hmer