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
>