On 8 April 2024 01:34:45 BST, Saki Takamachi <s...@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]
