Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108622
To: <rowan.collins@gmail.com>
Cc: "'PHP internals'" <internals@lists.php.net>
Date: Sun, 16 Feb 2020 15:13:23 +0100
Message-ID: <005b01d5e4d3$4015caa0$c0415fe0$@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdXkzLyF6WXN/lQwRjS+jmP6kEbCYw==
Content-Language: de
Subject: Re: [PHP-DEV] [RFC] Userspace operator overloading
From: jan.h.boehmer@gmx.de

> ) I know you're not alone in that feeling. If it turns out this is the
majority view, I think it answers a couple of open questions:
>
> Overload methods should definitely be named after operations, not =
symbols,
to remind people they are implementing addition, not giving new meaning =
to +
>=20
> They should probably be grouped into interfaces, which this RFC has so =
far
resisted. How often does it make sense for a type to support addition =
but
not subtraction, or multiplication but not division? Even more clearly, =
if a
type claims to implement bitwise OR but not bitwise AND, NOT, and XOR,
something is =20
> definitely fishy.
>
> You can't stop people using overloading DSL-style, but you can make it
obvious that it's not the intention of the feature (if we agree that =
it's
not the intention; maybe some people here are really hoping to use it =
that
way?)

On 16/02/2020 10:31, rowan.collins@gmail.com wrote:

Except for simple numbers, almost no mathematical objects define =
division
(only some special matrices can be on the right hand of a division, and =
for
vectors there is no definition for division at all). Also think of time
differences: $datetime1 - $datetime2 results in a DateInterval, but
$datetime1 + $datetime2 is not a meaningful operation (Datetime already =
has
a diff() method that do this).

Also it is not really possible to split multiplicative and additive =
methods
into different behavior, as when $a implements Additive Behavior it =
should
be possible to do an -$a, but because of the the way PHP compiles the =
code
this becomes -1*$a. This is sufficient for almost all cases, but it =
would
require that the code also provides an possibility to handle =
multiplication.

In my opinion this would lead to that even if an object implements these
interfaces, in many cases you cannot be sure that it really supports all
operations, which would contradict the whole idea of defining =
interfaces.

I wonder if it would be reasonable to allow voting between an interface
approach and the "separate magic function for each operator" approach...

Greetings,
Jan B=F6hmer