Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123555 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id EE1771A009C for ; Sat, 8 Jun 2024 00:29:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1717806632; bh=wZORmGOZIQFGapDTi292luKxAKjE20HQzzUJOY0oH9Y=; h=Subject:From:In-Reply-To:Cc:Date:References:To:From; b=EfKppL+xh0gVPdSzEVIAHpBuD5g9H3R9tOLIRjyaxuZxQdNPBJPrjzPWyQUnXb7Gf Kjn6LVAekObscUCevQbBFbzWCSTBQ2/DGzvYKc+fJJAxZ4rpbAzlAWfOOgvQmlu3zR VvhqhbbmsCfglpij0xbpZj/8vjhqwN+X2djvkwZqBcdle/fcWJUR2rGOC8lY4XFlp0 SuV8PNMY4STV9EQ1WvwhB3trv9imdW0qfPfri9457E0Y8TXRLC68c2bdgMKE5u9CVE ua5qKwVEufY/HESbAd/KBuOnDXkXJJO4umRowFgU+ydlzfLJ5FPIrCIwB1VfXyrw5Z 1EVLyzcnEZ9HQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B05BD18004B for ; Sat, 8 Jun 2024 00:30:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,HTML_MESSAGE, MIME_QP_LONG_LINE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail.sakiot.com (mail.sakiot.com [160.16.227.216]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 8 Jun 2024 00:30:29 +0000 (UTC) Received: from smtpclient.apple (unknown [117.55.37.250]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.sakiot.com (Postfix) with ESMTPSA id DE5BB401F3; Sat, 8 Jun 2024 09:29:20 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sakiot.com; s=default; t=1717806560; bh=wZORmGOZIQFGapDTi292luKxAKjE20HQzzUJOY0oH9Y=; h=Subject:From:In-Reply-To:Cc:Date:References:To:From; b=qZSaToPfchC9LhY43Lcp92qGRnN0bYxHkVxP0P8C7x9PLMGm3x0MbV7Vfe9u8qMxh 9TFut3kOfmqXovCoM8/rP3C6MImlD4DPyFKN2fn5h/wBa12KGYOpQHjqov727HI+FL 4SK9xdaRSCmUV1t0DBZE1+1CK4s56Qv34zOx9sLk= Content-Type: multipart/alternative; boundary=Apple-Mail-E7668A35-DC1E-4CA0-B30A-E9FAAFF60F13 Content-Transfer-Encoding: 7bit Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (1.0) Subject: Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum In-Reply-To: <9zUVZKaEYixjCLLhviQPYFQtSAEhsRMWL6xbKeogzAGsH-STebN9JqJxITAPVfdKTNu7gEs_m77OkIcOzaiscoajx8Hp8VWRKkhTTCPkGko=@gpb.moe> Cc: Jorg Sowa , php internals Date: Sat, 8 Jun 2024 09:29:08 +0900 Message-ID: <6E690732-8BED-4A01-8385-648E7CEDFD9F@sakiot.com> References: <9zUVZKaEYixjCLLhviQPYFQtSAEhsRMWL6xbKeogzAGsH-STebN9JqJxITAPVfdKTNu7gEs_m77OkIcOzaiscoajx8Hp8VWRKkhTTCPkGko=@gpb.moe> To: "Gina P. Banyard" X-Mailer: iPhone Mail (21F90) From: saki@sakiot.com (Saki Takamachi) --Apple-Mail-E7668A35-DC1E-4CA0-B30A-E9FAAFF60F13 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > =EF=BB=BFOn Sunday, 2 June 2024 at 22:26, Jorg Sowa w= rote: >> > by *removing* the newly introduced constant and instead exposing the fu= nctionality *only* via the new Enum. >>=20 >> It brings inconsistency that some modes are accessible by ints and enums a= nd others only by enums. If there is no deprecation plan yet I am not sure t= his is the right approach. >=20 > We cannot formally deprecate the constants in the same version as introduc= ing the enums as there would be no transition period. > We can however soft deprecate the usage of the constants in the documentat= ion by recommending to use the enumeration instead. >=20 > However, I don't see _any_ point in having both constants and enum cases f= or the new modes as there is no incentive what so ever to use the enum. > It is *by design* to have an inconsistency, you want the new feature, use t= he new and better way. >=20 > Let's imagine we do introduce those new constants alongside the enum, from= a user PoV there is no clear reason why one should use constants above enum= s or enums above constants, except if you care about type safety. > Now, let's fast forward in this imaginary world and we decide to formally d= eprecate the constants and tell people to use the enum. > For every single user that decided to use the constants, especially for th= e new rounding modes, they now need to go and fix their code because we didn= 't clearly incentivise people to use, what I deem, to be the recommended way= forward. >=20 > Moreover, this equivalence will be an argument _against_ deprecating the c= onstants. > And finally, if we decide to add actual support for half up/down rounding,= there is no way to establish an equivalence with a sanely named constant be= cause the name is already taken for an incorrect mode. >=20 > So once again, if this RFC does not remove the constants for the new round= ing mode I see less of a point, because it is "just" improving the naming (w= hich is really needs considering how bonkers wrong it currently is). > This RFC *must* be passed for 8.4 to ammend your RFC, because I frankly do= n't want to be doing clean-up on yet another bad decision the project did th= at will haunt us for decades if the current state gets released. >=20 > Best regards, >=20 > Gina P. Banyard To summarize the discussion so far, it seems that there is a lot of support f= or the concept of this RFC itself. The current points of discussion are the following two points:=20 1. Whether or not to provide the new rounding modes added in 8.4 as constant= s. 2. Naming of modes equivalent to floor/ceiling Regarding 1, personally, I support Gina's opinion of only providing the new r= ounding modes as an Enum. This can be interpreted as changing the rounding mode to Enum, with the exis= ting constants being kept simply for backward compatibility. Regarding 2, I like the PositiveInfinity/NegativeInfinity expression. As far= as I know, there doesn't seem to be a clear distinction between these and c= eil/floor. There are several other expressions, such as upward and plus inf, but they a= ll seem to refer to the same concept.=20 Regards, Saki= --Apple-Mail-E7668A35-DC1E-4CA0-B30A-E9FAAFF60F13 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

=EF=BB=BF= On Sunday, 2 June 2024 at 22:26, Jorg Sowa <jorg.sowa@gmail.com> wrote= :
> by *removing* the newly introduced constant= and instead exposing the functionality *only* via the new Enum.

It brings inconsistency that some modes are accessible by ints a= nd enums and others only by enums. If there is no deprecation plan yet I am n= ot sure this is the right approach.

We cannot formally deprecate the constants in the same ver= sion as introducing the enums as there would be no transition period.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0= , 0); background-color: rgb(255, 255, 255);">We can however soft deprecate t= he usage of the constants in the documentation by recommending to use the en= umeration instead.

<= /div>
However, I don't see _an= y_ point in having both constants and enum cases for the new modes as there i= s no incentive what so ever to use the enum.
It is *by design* to have an inconsistency, you want the= new feature, use the new and better way.

L= et's imagine we do introduce those new constants alongside the enum, from a u= ser PoV there is no clear reason why one should use constants above enums or= enums above constants, except if you care about type safety.
Now, let's fast forward in this imagin= ary world and we decide to formally deprecate the constants and tell people t= o use the enum.
For ever= y single user that decided to use the constants, especially for the new roun= ding modes, they now need to go and fix their code because we didn't clearly= incentivise people to use, what I deem, to be the recommended way forward.<= /div>

Moreover, this equivalence will be an argum= ent _against_ deprecating the constants.
And finally, if we decide to add actual support for half up= /down rounding, there is no way to establish an equivalence with a sanely na= med constant because the name is already taken for an incorrect mode.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0= , 0); background-color: rgb(255, 255, 255);">
So once again, if this RFC does not remove the con= stants for the new rounding mode I see less of a point, because it is "just"= improving the naming (which is really needs considering how bonkers wrong i= t currently is).
This RFC= *must* be passed for 8.4 to ammend your RFC, because I frankly don't want t= o be doing clean-up on yet another bad decision the project did that will ha= unt us for decades if the current state gets released.

<= div style=3D"font-family:Arial, sans-serif">
Best regards,

Gina= P. Banyard


To summarize the discus= sion so far, it seems that there is a lot of support for the concept of this= RFC itself.

The current points of discussion are t= he following two points: 

1. Whether or not to= provide the new rounding modes added in 8.4 as constants.
2. Nami= ng of modes equivalent to floor/ceiling

Regarding 1= , personally, I support Gina's opinion of only providing the new rounding mo= des as an Enum.
This can be interpreted as changing the rounding m= ode to Enum, with the existing constants being kept simply for backward comp= atibility.

Regarding 2, I like the PositiveInfinity= /NegativeInfinity expression. As far as I know, there doesn't seem to be a c= lear distinction between these and ceil/floor.
There are several o= ther expressions, such as upward and plus inf, but they all seem to refer to= the same concept. 

Regards,

Saki
= --Apple-Mail-E7668A35-DC1E-4CA0-B30A-E9FAAFF60F13--