Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90096
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.169 as permitted sender)
Message-ID: <BLU436-SMTP124D17326572A7805BBA820E2F30@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
In-Reply-To: <CAEbg-4bi8C-Rqz5yw-SMej_x=y6Fj4SRdNH3VB-DiB4QXpekmQ@mail.gmail.com>
Date: Tue, 5 Jan 2016 16:01:01 +0100
CC: Andrea Faulds <ajf@ajf.me>,
 PHP internals list <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com> <12.34.07292.41F9A865@pb1.pair.com> <568AF408.6020105@gmail.com> <68.B0.07292.98AFA865@pb1.pair.com> <CAEbg-4bi8C-Rqz5yw-SMej_x=y6Fj4SRdNH3VB-DiB4QXpekmQ@mail.gmail.com>
To: Alexander Lisachenko <lisachenko.it@gmail.com>
Subject: Re: [PHP-DEV] RFC Operator Overloading in Userspace
From: bobwei9@hotmail.com (Bob Weinand)


> Am 05.01.2016 um 15:29 schrieb Alexander Lisachenko =
<lisachenko.it@gmail.com>:
>=20
> 2016-01-05 2:04 GMT+03:00 Andrea Faulds <ajf@ajf.me>:
>=20
>> I agree that we could do something with interfaces. I would like to =
point
>> out that we actually already have an example of this, in the form of =
the
>> \ArrayAccess interface, which requires you to implement all the =
different
>> indexing operations at once. Unfortunately, though, \ArrayAccess =
doesn't
>> give us a precedent for dealing with the $this issue (in `$a + $b`, =
who
>> gets called, how do we handle differing types, etc?), but it's a =
start.
>>=20
>=20
>=20
> Hi, Andrea and internals team!
>=20
> Interface is a good way to implement new functionality for classes, =
but
> operator overloading is language feature itself, so from my point of =
view,
> it will be better to put this functionality into the magic method.
> Personally, I don't like hundreds of __add, __mul, __etc methods, =
because
> this will be ugly and will require addition of new methods when new
> operators are included (eg __pow).
>=20
> I want to suggest to add only one single method:
>=20
> public function __operator(int $operatorKind, ...$operatorArgs);
>=20
> This method will be called for every operator and class can check the
> $operatorKind variable with simple check: if =
(Php\Operator::OP_DIVISION =3D=3D=3D
> $operatorKind) return $operatorArgs[0]->value / =
$operatorArgs[1]->value;
> New values for operator type enumeration can be added later into new
> versions of PHP easily.

I think an interface is a strongly superior way, especially as it'll =
allow you to hint that an implementation became incomplete when an =
operator has been added. (Also, how often are relevant operators added?)
At least as you aren't supposed to *ab*use the methods for other things =
than they're intended to. If you implement number operations, then you =
should implement the whole set of them.
If you implement a string class, you should implement the array access =
and the string concat.

Operators definitely shouldn't have specific context sensitive meaning =
(like printing when you bitshift (wtf, C++?)).
At least, we should *assume* that the operators are used in accord with =
their intended meaning.

Bob=