On 07/04/2024 14:27, Saki Takamachi wrote:
If we really wanted decimal to be a native type, then the rounding
mode and scale behavior should be completely fixed and not user
selectable. If not, decimal should be implemented as a class.
As I replied to Jordan, I don't see why this is connected to "scalar" vs
"object" types at all. An object - particularly an immutable one - is
just a way of declaring a type, and some syntax for operations on that
type. There's really no difference at all between these:
$half = $whole / 2;
$half = numeric_div($whole, 2);
$half = $whole->div(2);
In PHP, right now, the last one is only available on objects, but there
have been proposals in the past to change that; it's just syntax.
For rounding, the first one is the real problem, because there's nowhere
to put an extra operand. That problem is the same for a class with an
overloaded "/" operator, and a "scalar" type which has a definition of
"/" in the engine.
Maybe it feels more obvious that an object can carry extra state in
private properties, but internal types don't actually need private
properties at all. PHP's "array" type has a bunch of different state
without being an object (a linked list of items, a hashtable for random
access, an iteration pointer, etc); and SimpleXMLElement and DOMNode are
exposed in PHP as separate classes, but actually store state in the same
C struct provided by libxml2.
So I see it just as an API design decision: do we specify the rounding
mode of numeric division a) on every operation; b) on every value; c) in
a runtime setting (ini_set); d) in a lexically scoped setting (declare)?
My vote is for (a), maybe with (d) as a fallback.
Regards,
--
Rowan Tommins
[IMSoP]
