Re: Proposal: Arbitrary precision native scalar type

From: 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]

« previous php.internals (#123032) next »