Re: [RFC] [Discussion] Add 4 new rounding modes to round() function
| From: | Tim Düsterhus | Date: | Wed, 06 Sep 2023 17:40:48 +0000 |
| Subject: | Re: [RFC] [Discussion] Add 4 new rounding modes to round() function | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120997@lists.php.net to get a copy of this message | ||
Hi
On 9/5/23 00:34, Jorg Sowa wrote:
I didn't intent to suggest putting the enum into a namespace. It would beIntroducing 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
\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 toFor 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