Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128586
Content-Type: text/plain; charset=utf-8
Message-ID: <1756399368311.4054485786.1195379738@yahoo.de>
To: tim@bastelstu.be, Morgan <weedpacket@varteg.nz>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add clamp function
Date: Thu, 28 Aug 2025 16:54:54 +0000
In-Reply-To: <f25b801a36c86b37e79e16ee42b14a63@bastelstu.be>
References: <f25b801a36c86b37e79e16ee42b14a63@bastelstu.be>
User-Agent: Vivaldi Mail/7.5.3735.64
Content-Transfer-Encoding: quoted-printable
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)




On Thursday 28 August 2025 13:28:43 (+02:00), Tim D=C3=BCsterhus wrote:

> Hi
>=20
> >> There's precedent in ext/random with the Randomizer::getFloat() method=
 that takes a Random\IntervalBoundary enum to decide on the the =
interpretation of the boundary values. Translated to `clamp()` this could =
mean:
> >> > If it weren't living in the Random extension, that very Enum could =
have been used.
>=20
> Indeed. Back when introducing the enum, we actually had a discussion =
about naming and =E2=80=9Cplacement=E2=80=9D. In the end, we opted to make =
it ext/random-specific as a more conservative choice. I think back then it =
was the first native enum.
>=20
> See https://externals.io/message/118810#118910 and https://chat.=
stackoverflow.com/transcript/11?m=3D55444127#55444127.
>=20
> If a new general-purpose IntervalBoundary enum is introduced, I'm happy =
to widen the type in ext/random from `\Random\IntervalBoundary` to =
`\IntervalBoundary|\Random\IntervalBoundary` (and deprecate the latter in =
one of the following versions).
>=20
> Best regards
> Tim D=C3=BCsterhus
>=20

Not sure if I'm too much off track here: As we can't alias classes in =
userland that are internal classes, internally PHP could do the oppsite and=
 given clamp could borrow it out to/from \Random\IntervalBoundary given we =
have enough discipline. That also could buy some time on the widening idea =
and preserve a bit of the conservative approach to further on defer the =
details until necessary.

Widening is certainly correct in its own right, but why not keep the door =
open this way so one day we can applaud the first internal enum for its =
foresight?

-- hakre