Re: [RFC] [Discussion] Add clamp function
| From: | Hans Krentel | Date: | Thu, 28 Aug 2025 06:36:52 +0000 |
| Subject: | Re: [RFC] [Discussion] Add clamp function | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-128578@lists.php.net to get a copy of this message | ||
On Wednesday 27 August 2025 18:40:51 (+02:00), Larry Garfield wrote:
> ...So it looks like CSS is the oddball here. We should follow the clear
> majority approach...
While the majority of languages favor
clamp($value, $min, $max),
dismissing the CSS order without examining the "why" misses a valuable
perspective, especially for a language so intertwined with web development.
The rationale for aligning with the majority (and the current RFC) boils
down to the **Principle of Least Surprise within PHP's own ecosystem**.
PHP is an imperative language. Its standard library functions,
particularly in math, consistently take the value to be operated on as
the first argument: min($value1, $value2), max($value1, $value2),
round($value, $precision). Introducing clamp($min, $value, $max)
would break this pattern, making it the odd one out *within PHP itself*.
This internal inconsistency would be a greater source of errors for PHP
developers than not matching an external standard like CSS.
The solution to the CSS dissonance is not to change the function but to
**document it explicitly**:
> **Note for Web Developers:** This function uses the argument order
> clamp(value, min, max), which differs from the CSS function
> clamp(min, value, max).
This addresses the concern head-on. The ultimate win is not the argument
order itself, but the mere existence of the function, which finally
banishes the awkward and error-prone max($min, min($max, $value))
incantation.
My 2cents,
--hakre