Re: Proposal: Arbitrary precision native scalar type
| From: | Rowan Tommins [IMSoP] | Date: | Mon, 08 Apr 2024 08:05:37 +0000 |
| Subject: | Re: Proposal: Arbitrary precision native scalar type | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-123032@lists.php.net to get a copy of this message | ||
On 8 April 2024 01:34:45 BST, Saki Takamachi <saki@sakiot.com> wrote:
>
> I'm making these opinions from an API design perspective. How the data is held internally
> is irrelevant. zval has a lot of data other than values. What I want to say is that if multiple
> types of parameters are required for initialization, they may only serve as a substitute for object
> for the user.
Again, that only seems related to objects because that's what you're used to in PHP, and
even then you're overlooking an obvious exception: array(1, 2)
If we ever do want to make decimals a native type, we would need some way to initialise a decimal
value, since 1.2 will initialise a float. One of the most obvious options is a function-like syntax,
decimal(1.2). If we do want numbers to carry extra information in each value, it will be no problem
at all to support that.
On the other side, just because something's easy doesn't mean it's the right
solution. We could make an object which contained a number and an operation, and write this:
$a = new NumberOp(42, 'add');
$b = $a->exec(15);
$c = $b->withOperation('mul');
$d = $c->exec(2);
I'm sure you'd agree that would be a bad design.
So, again, I urge you to forget about it being easy to stick an extra property on an object, and
think in the abstract: does it make sense to say "this number has a preferred rounding
mode", rather than "this operation has a preferred rounding mode".
Regards,
Rowan Tommins
[IMSoP]