Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123022
Feedback-ID: id5114917:Fastmail
Message-ID: <002f0cdd-55fe-48b6-87c3-fcc4dd4c9ecd@rwec.co.uk>
Date: Sun, 7 Apr 2024 19:39:39 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: internals@lists.php.net
References: <3c74f433-be6b-4f20-beb0-f09db2fb39b6@rwec.co.uk>
 <494F7C68-81FC-49DE-A292-A782F7C79DB1@sakiot.com>
Content-Language: en-GB
In-Reply-To: <494F7C68-81FC-49DE-A292-A782F7C79DB1@sakiot.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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]