Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123029
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
In-Reply-To: <002f0cdd-55fe-48b6-87c3-fcc4dd4c9ecd@rwec.co.uk>
Date: Mon, 8 Apr 2024 09:34:45 +0900
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <AE5FF4B5-BDA5-4E90-970A-4C99E5CC70D1@sakiot.com>
References: <3c74f433-be6b-4f20-beb0-f09db2fb39b6@rwec.co.uk>
 <494F7C68-81FC-49DE-A292-A782F7C79DB1@sakiot.com>
 <002f0cdd-55fe-48b6-87c3-fcc4dd4c9ecd@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: saki@sakiot.com (Saki Takamachi)

Hi Rowan

> 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:
>=20
> $half =3D $whole / 2;
> $half =3D numeric_div($whole, 2);
> $half =3D $whole->div(2);
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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)?
>=20
> My vote is for (a), maybe with (d) as a fallback.

There is no difference in how the data is held. Agree. What I'm =
referring to is how to initialize the value. If the user has to specify =
some parameters, or can specify them as options, that is already the =
behavior of the object.

 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.

Regards.

Saki=