Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120997
Message-ID: <606297dd-8964-7df4-df67-579f1b2f37e8@bastelstu.be>
Date: Wed, 6 Sep 2023 19:40:48 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Jorg Sowa <jorg.sowa@gmail.com>
Cc: =?UTF-8?Q?Alexandru_P=c4=83tr=c4=83nescu?= <drealecs@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAPTD5yEcwBNUe2Y9vvmHaigFtvRixJ0anTuLk4zXOKvBhrUOig@mail.gmail.com>
 <7f23f0ac-bba6-5997-b737-2a252205cf85@bastelstu.be>
 <CAAwdEzDGa+16bc0Hhmnzau6vkGpfRFqiRetw7V7KGbjsTyS8Cg@mail.gmail.com>
 <9a19120d-1767-6214-c728-c67a9a98f977@bastelstu.be>
 <CAPTD5yHQnP8RQJVZg4MTPkHk6yVhnr+rqdffNaE6_TM_zb9+NA@mail.gmail.com>
In-Reply-To: <CAPTD5yHQnP8RQJVZg4MTPkHk6yVhnr+rqdffNaE6_TM_zb9+NA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round()
 function
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 9/5/23 00:34, Jorg Sowa wrote:
>> Introducing a brand-new RoundingMode enum (using union types) I
>> suggested in my first email would nicely solve the naming problem and
>> would also make the API more obvious to use due to stronger typing in
>> the long run.
> 
> That's also interesting idea and I would push it, however I'm afraid about
> the naming of namespace. I recollect some of the RFCs were rejected simply


I didn't intent to suggest putting the enum into a namespace. It would 
be `\RoundingMode` (i.e. within the global namespace). I'm not sure how 
you got the impression I suggest a namespace.

> because of the namespace. If there is a guideline for the namespace of core
> functions I would willingly get familiar to it. Otherwise, I don't want to


For the reference, there is a namespace guideline here: 
https://wiki.php.net/rfc/namespaces_in_bundled_extensions

It doesn't really apply here, because `round()` is in ext/standard.

> open Pandora box only because of the namespace of Enum. It would also bring
> BC to the function, unless we would accept both enum and old constants.
> 

Yes it would accept both the enum and the constants. In the long run the 
constants could be deprecated. Alternatively the constants could be 
aliases for the enum values, but this might break compatibility for 
users that use the raw integers instead of the constants. While this is 
"not a good idea", it might have happened.

Best regards
Tim Düsterhus