Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116679
Date: Fri, 17 Dec 2021 22:24:33 +0100
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAJF_ukXpNEXtn9FT1xtWFWsMWaBB-TrFp6iq0c0DxKbZb636Ww@mail.gmail.com>
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com> <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com> <CAMrTa2E9STK3G52mnQ9UsrUqi_bH4SMUzcE76PEGcxcLzGPVZA@mail.gmail.com> <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org> <CAB-BujbjgBBNdLjf+8SxWKJrv3J3CU8Mv51n4AkCwpsOt5WekA@mail.gmail.com> <CAMrTa2Fk2R8PB77Ws7dcfwRw-NWfmH4AzJkNgehA1WR4Nr1StQ@mail.gmail.com> <CAJF_ukUKYdwyQ8g2VScOxtpSfUR7R5VjeDWcxCXRTeqAGU1E5A@mail.gmail.com> <CAMrTa2HAtBYePLsgONR_618uBZctp9YBoScGgLYwWNXwmwBr_w@mail.gmail.com> <CAJF_ukXpNEXtn9FT1xtWFWsMWaBB-TrFp6iq0c0DxKbZb636Ww@mail.gmail.com>
Message-ID: <5DB9C8A8-C760-4D3D-9DDC-54B5A135358F@dafert.at>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: mel@dafert.at (Mel Dafert)

Hello internals,

>register_operator(*, function (Foo $lhs, Bar $rhs): Foo { =2E=2E=2E});
>register_operator(*, function (Bar $lhs, Foo $rhs): Foo { =2E=2E=2E});
>register_operator(*, function (int $lhs, Foo $rhs): int { =2E=2E=2E});
>
>But this just brings a new set of problems, including visibility issues
>(i=2Ee=2E can't use private fields in the implementation), and the fact t=
hat
>this requires executing a function at runtime rather than being defined a=
t
>compile time=2E

Since this is going deeply into magic land anyways, we could go another st=
ep further
and make this a builtin/"macro" that does happen at compile-time, but also=
 can
impose additional restrictions on what is
allowed - namely, that the registered function must not be inlined but a s=
tatic
method on one of the arguments=2E

For example: (syntax completely imaginary here but slightly inspired by ru=
st):

register_operator!(+, lhs: Bar, rhs: Foo, ret: Bar, Bar::addFooBar);
register_operator!(+, lhs: Bar, rhs: Bar, ret: Bar, Bar::addBar);
register_operator!(+, lhs: int, rhs: Bar, ret: int, Bar::addBarInt);
register_operator!(+, lhs: Foo, rhs: int, ret: Foo, Foo::addFooInt, commut=
ative: true);

with

class Bar {
    =2E=2E=2E
    public static addFooBar (Bar $bar, Foo $foo): Bar { }
    // etc=2E
}

Advantages:
- Explicitly named methods that can be called/tested separately
- Slightly improved searchability - grepping "register_operator" will show=
 all operator
combinations inside a code base
- Cannot implement operators for arbitrary classes that one does not own -=
 the method
must be from one of the operands
- Multiple distinct methods per operand/class without full method overload=
ing
- No restrictions around having scalar types only as rhs

If I am not mistaken, the engine should also be able to typecheck the meth=
ods
to ensure that the types are correct, and additionally also be able to dis=
allow
overlaps (eg=2E defining Foo+Bar commutitatively as well as Bar+Foo),
which should throw an error as soon as the second definition is encountere=
d=2E

Disadvantage: This sounds like a lot of work to implement, and I am not su=
re
if the checks are even possible the way I'm imagining them (with classes b=
eing
loaded on demand, etc=2E)=2E
Also, this syntax would definitely need work, I just wanted to point out t=
hat on the
drawing board, many of these design problems are solvable=2E

Whether they are worth the effort, and whether this is a good idea at all,=
 is left
for others to decide=2E

Regards,
Mel