Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116700
MIME-Version: 1.0
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>
 <67431363-cd1e-9575-7d51-0f4d265d05b9@gmail.com> <CA+kxMuSehufPoGWSF-Wi_spk550O0Cm6DDQQBgYeaLGZbMZESA@mail.gmail.com>
 <CAB-BujZTaANvFQPYzAuc7ap9J8zpSk2Bu9oGGZexvr5rEqQy5Q@mail.gmail.com> <7285dd63-42f4-dcd1-6549-178157858abd@gmail.com>
In-Reply-To: <7285dd63-42f4-dcd1-6549-178157858abd@gmail.com>
Date: Tue, 21 Dec 2021 14:06:27 +0100
Message-ID: <CAB-BujZWRwoQWXHME4_Dt=Y+1MmoUgz2zLZPf62XBT=8MKm1kw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: andreas@dqxtech.net (Andreas Hennings)

On Tue, 21 Dec 2021 at 10:13, Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> On 21/12/2021 00:43, Andreas Hennings wrote:
> > I think the example in the RFC is interesting, but not ideal to
> > advertise the RFC.
> > The example is with native scalar types and build-in operator implementations.
> > (I don't know how GMP works internally, but for an average user of PHP
> > it does not make sense to call this "overloaded")
>
>
> I think you have misunderstood the example. GMP doesn't work with scalar
> types, it works with its own objects; the general approach is to call
> gmp_init() with a string describing a large number that cannot be
> represented by a PHP integer. This gives you an object which doesn't
> have any methods (it replaced a resource in older versions), but can be
> used with the gmp_* functions, and with mathematical operators
> overloaded in the engine.

Wow, you are right. I should read more before I post.
Thank you Rowan!
Sorry everybody for the distraction.

>
> So the questions you posed are not hypothetical:

Indeed.
The "concern" already applies for those extension-provided operator overloads.

>
> > - Are those variables scalar values, or objects?
> > - Are the operators using the built-in implementation or some custom
> > overloaded implementation? (depends on the operand types)
> > - Are the return values or intermediate values scalars or objects?
>
> They are objects, using an overloaded implementation of the operators,
> and returning more objects.

Well the initial values could be scalar or GMP. As soon as we hit any
gmp_*() function, the return type is going to be GMP.
In the rewritten example using mostly operators, the gmp_invert() is
the only part that guarantees the return type to be GMP.
Without that gmp_invert(), the return value could as well be scalar,
if all initial variables are.

float|GMP * float|GMP = float|GMP
gmp_mul(float|GMP, float|GMP) = GMP

>
> The only difference is that right now, you can only overload operators
> in an extension, not in userland code.

So the same "concern" already applies here,
But it can be outweighed by the benefit.

>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>