Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123473
Precedence: bulk
MIME-Version: 1.0
References: <81CBE5A8-9FAF-40DA-8EAB-9F19C2278E75@sakiot.com>
In-Reply-To: <81CBE5A8-9FAF-40DA-8EAB-9F19C2278E75@sakiot.com>
Date: Fri, 31 May 2024 12:11:02 -0300
Message-ID: <CAGS0MVBr7LS9dFCrOZRe034+NWX6aFS9AsMCowy-5dRFMSUMjg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and
 make it an Enum
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007e9d480619c16667"
From: ericklima.comp@gmail.com (Erick de Azevedo Lima)

--0000000000007e9d480619c16667
Content-Type: text/plain; charset="UTF-8"

> To resolve these issues, change the naming to something appropriate and
use Enums instead of int constants.

Hi!
I like the idea. But I don't know

From the RFC text:
> To summarize, existing features will be changed to a union type of int|
\RoundingMode, and unreleased features will only accept \RoundingMode as
the rounding mode argument.

I have mixed feelings about the unreleased features using a different
typing for the same parameters that already exist in the existing features.
On one side, the user would be forced to use the new approach and get used
to it when they start to use the unreleased features, but on the other
side, the code would be strange with 2 different approaches for similar
features of the same "feature set".

I think that I would use union types for everything and plan the
deprecation and further removal of the Int version for the next releases
for everything.

Anyway, I'm in favor of starting the movement of changing these Ints to
Enums.

Thanks for working to make PHP better!

Best regards,
Erick

--0000000000007e9d480619c16667
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">&gt; To resolve these issues, change the =
naming to something appropriate and use Enums instead of int constants.</di=
v><div dir=3D"ltr"><br></div><div>Hi!</div><div>I like the idea. But I don&=
#39;t know</div><div><br></div><div>From the RFC text:<br></div><div>&gt; T=
o summarize, existing features will be changed to a union type of <code cla=
ss=3D"gmail-code gmail-php">int<span class=3D"gmail-sy0">|</span>\RoundingM=
ode</code>, and unreleased features will only accept <code class=3D"gmail-c=
ode gmail-php">\RoundingMode</code> as the rounding mode argument.</div><di=
v><br></div><div>I have mixed feelings about the unreleased features using =
a different typing for the same parameters that already exist in the existi=
ng features. On one side, the user would be forced to use the new approach =
and get used to it when they start to use the unreleased features, but on t=
he other side, the code would be strange with 2 different approaches for si=
milar features of the same &quot;feature set&quot;.<br><br>I think that I w=
ould use union types for everything and plan the deprecation and further re=
moval of the Int version for the next releases for everything.</div><div><b=
r></div><div>Anyway, I&#39;m in favor of starting the movement of changing =
these Ints to Enums.</div><div><br></div><div>Thanks for working to make PH=
P better!</div><div><br></div><div>Best regards,<br></div><div>Erick<br></d=
iv></div>

--0000000000007e9d480619c16667--