[RFC] Support object types in BCMath

[SakiTakamachi]

https://wiki.php.net/rfc/support_object_type_in_bcmath
https://wiki.php.net/rfc/fix_up_bcmath_number_class

[zmitic]

Sorry for barging as end-user, but I am really interested if this RFC will allow lazy evaluation.

For example:

class LazyInt extends Number
{
	private int|null $cachedValue = null;

    /** 
     * @param Closure(): int $closure 
     */
    public function __construct(private Closure $closure){}

	#[Override]
    public function getValue(): int
    {
        return $this->cachedValue ??= ($this->closure)(); // one-time lazy evaluation
    }
}

and then use like:

function slow(): int
{
	sleep(5); // some slow query

	return 42;
}

$lazy1 = new LazyInt(fn() => slow()); // nothing happens
$lazy2 = new LazyInt(fn() => slow()); // nothing happens

$lazy1 + $lazy2; // sleeps 10 seconds, returns Number(84);
$lazy1 + $lazy2; // no sleep, returns Number(84);

---

This lazy evaluation has many use-cases, but it would require something like this:

class Number extends \Stringable
{
	public function getValue(): string|int;
}

[SakiTakamachi]

@zmitic

After much discussion, it was decided that this class should be marked final, so it cannot be inherited :)

https://wiki.php.net/rfc/support_object_type_in_bcmath

[zmitic]

@SakiTakamachi
Thanks, I thought it was still under discussion but externals are too hard to read with nested comments.

Last one, I promise: will you be open to create NumberInterface that users could implement? This would open the door to many new things. But by locking users from custom implementations, I think that operator overload will never become a thing.

[SakiTakamachi]

I'll merge this after CI passes

I made a mistake in the PR 😱

[SakiTakamachi]

Editing the comment was not enough so I will comment again. The following comment is incorrect.

#13741 (comment)

Actually, I was trying to comment on the next PR, but accidentally commented on this one.

#14297 (comment)

[Girgias]

Why is null accepted here? This doesn't seem to be the case, looking at the signatures?

[SakiTakamachi]

@Girgias

This is for the same reason that there are problems with operators on GMP objects and null.

When merged this, it was intended to match the behavior of regular operators.

Since this behavior should be consistent, it would be best to discuss it together in my PR thread on GMP.

[Girgias]

ACK.