Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121207
Message-ID: <9361B7A5-82C6-4A25-9524-09CEEE1A6CE4@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_49381D22-0303-48D3-86AF-C496CC2D9D02"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Mon, 2 Oct 2023 19:23:16 +0200
In-Reply-To: <A6916252-E0AD-4485-B2E1-1A2DE5D674E4@sakiot.com>
Cc: PHP internals <internals@lists.php.net>
To: Saki Takamachi <saki@sakiot.com>
References: <A6916252-E0AD-4485-B2E1-1A2DE5D674E4@sakiot.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil
 to BCMath
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_49381D22-0303-48D3-86AF-C496CC2D9D02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 1 oct. 2023 =C3=A0 14:35, Saki Takamachi <saki@sakiot.com> a =C3=A9cr=
it :
>=20
> Hi, internals
>=20
> I would like to start the discussion for my RFC "Adding bcround, =
bcfloor and bcceil to BCMath=E2=80=9D.
> https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
>=20
> Regards.
>=20
> Saki
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20


Hi,

Some remarks about the paragraph =E2=80=9CBackward Incompatible =
Changes=E2=80=9D

> These are new features and do not break existing functionality.
>=20
> If I had to point out my concerns, I would say that code that =
satisfies the following conditions will cause an error to occur.
>=20
> * A situation where the user has defined a function with the same =
name, such as bcround()

This is a real concern. I have personally defined a `bcround()` global =
function because I needed such a functionality. A quick search on GitHub =
shows that I am not alone: =
https://github.com/search?q=3Dbcround+language%3Aphp&type=3Dcode=20

>=20
> * And, the existence of the function is not checked in advance.

If the existence of the function is checked in advance, the BC risk is =
worst, because they cannot have known whether the signature and =
semantics of the function you will introduce will be compatible with the =
one they have defined. In case of mismatch the eventual breakage could =
be more difficult to notice and trace back.

Note in particular this SO question: =
https://stackoverflow.com/questions/231057/how-to-round-ceil-floor-a-bcmat=
h-number-in-php, where the second answer has a different rounding mode =
on halves than the first and third answers.

Fortunately, the few examples I have seen don=E2=80=99t foolishly guard =
the definition with `if (!function_exists(...))`, so that there will be =
a hard break when upgrading PHP (static error: function already =
defined), and they=E2=80=99ll have to decide explicitly what to do.

In my case, I=E2=80=99ll wait until this RFC is accepted, then (and only =
then) I=E2=80=99ll decide what to do depending on whether my version of =
`bcround()` is compatible with yours (either rename or =
`function_exists()` guard).

>=20
> However, I do not think it is necessary to consider these matters.

I think that it is necessary to acknowledge that there will be breakage =
for some people, and to decide explicitly whether this breakage is =
acceptable. (I think it is.)

=E2=80=94Claude


--Apple-Mail=_49381D22-0303-48D3-86AF-C496CC2D9D02--