Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128552
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 25 Aug 2025 08:49:59 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <9742b754-6544-41ee-bc26-08d48f5c9b73@app.fastmail.com>
In-Reply-To: 
 <CANBC5nrdA3L_Ut+kZFmtACmdATjw0Xx1grEWjckPeDj14MF5WQ@mail.gmail.com>
References: 
 <CANBC5np5gFoG2vy572K_rV5df58qBJdQuKsmYdHiprA2mLPWUg@mail.gmail.com>
 <c9acda400885e3c78775e400cb492538@bastelstu.be>
 <CANBC5noypta7=YvVaAB6sPFhQKQCxJTFMQZ7fEShii2isya49A@mail.gmail.com>
 <0027ab13-89fb-40b4-991b-2f88a35c2f31@gmx.de>
 <CANBC5npgKA2T51t9=CD8LcqZsbLY-mW1GUepyGkZLPEGtVxoPA@mail.gmail.com>
 <272c241b-3145-4069-8a6a-9ea877f936c0@app.fastmail.com>
 <CANBC5npestDfHkGVd8LPZyz8Wxx4zuQApj5C-d=qp0Q=tvCVTQ@mail.gmail.com>
 <cbd359d2-c80a-4ae1-b9c3-16e2cbfc617a@app.fastmail.com>
 <bae5adb0-7b81-4178-915c-5d7c2633f1c0@app.fastmail.com>
 <CANBC5nrdA3L_Ut+kZFmtACmdATjw0Xx1grEWjckPeDj14MF5WQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Add clamp function
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Aug 24, 2025, at 9:41 AM, Kyle Katarn wrote:

>>> (No need to change it in this RFC, just note explicitly that the exp=
ected behavior is identical to that min(max()) construct, regardless of =
type.)
>>>=20
>>> --Larry Garfield
>>>=20
>>=20
>> It only compares the first property, and if there is a conflict, it m=
oves on to the next property. That is why some of us have been advocatin=
g for operator overrides: because this default isn=E2=80=99t always appr=
opriate, as your Point example illustrates. In some cases, you would wan=
t to compare magnitude or something else entirely, not just the x value.
>>=20
>> What is even trickier is that this process completely ignores compute=
d hooks. So, if you add a hook as the first property (for example, retur=
ning the magnitude), it is simply ignored. As a weird side note: if you =
cast the object to an array, the computed hook disappears, but if you us=
e `json_encode()`, the computed value is included.
>>=20
>> To complicate things further, the current behaviour for objects is ac=
tually =E2=80=9Cundefined=E2=80=9D and it isn=E2=80=99t documented. Ther=
e are examples that show how objects are compared, but they don=E2=80=99=
t explicitly mention that the object is being cast to an array (see the =
above paragraph on why that matters). Because this relies on implementat=
ion details rather than documented behaviour, it could change between PH=
P versions without an RFC. That makes relying on it a bit risky.
>>=20
>> Adding operator overrides would help by making this behaviour explici=
t and consistent across versions, or just defining it in general. But wh=
enever someone tries to define this more clearly (as I started to do wit=
h Records), it tends to run into resistance on this list for reasons I=E2=
=80=99ve never quite understood.
>>=20
>> =E2=80=94 Rob
>
> I would not be against operator overrides, though it starts becoming=20
> quite complex when dealing with comparing 2 objects of different=20
> classes. Anyway I will add a note on the RFC about objects to warn=20
> about unexpected behavior, but this is probably out of scope, the same=20
> concerns apply to min() and max() and that's why I added the same=20
> warning in the documentation: "Be careful when passing arguments of=20
> different types because clamp can produce unpredictable results."=20
> Adding a specific note about objects in the documentation could make=20
> sense. Then it would probably be nice if it were also added to min()=20
> and max().

Overrides are their own complex beast, not to be tackled here.  Just mak=
ing sure the RFC is explicit about comparison behavior (and that it's we=
ird in the same ways PHP is already weird) is sufficient.

--Larry Garfield