Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126048
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 24 Nov 2024 15:47:28 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <953119a4-39fe-4054-a72d-64f71052c191@app.fastmail.com>
In-Reply-To: <7c82a45e-6516-4bcf-a00f-3d994d4be2f4@rwec.co.uk>
References: <18b85ba5-5f1c-489c-9096-3ae203977fbe@app.fastmail.com>
 <66b25296-ca81-4029-b6f6-064cfd810635@app.fastmail.com>
 <7c82a45e-6516-4bcf-a00f-3d994d4be2f4@rwec.co.uk>
Subject: Re: [PHP-DEV] [RFC] Data Classes
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Nov 24, 2024, at 8:38 AM, Rowan Tommins [IMSoP] wrote:
> Hi Larry,
>
> I think that's a useful breakdown of the concepts involved. I don't 
> think it's a bad thing to have a feature that covers multiple of them - 
> common cases shouldn't need a long string of modifiers like "immutable 
> copyonwrite valueequality class Point { ... }" - but being explicit 
> about what we are and are not including is wise.
>
> There is one point I'd like to nitpick on, though:
>
>
> On 23/11/2024 20:35, Larry Garfield wrote:
>> 3. Physical equality.  This is what === does, and checks that two variables refer to the same memory location.  Physical equality implies logical equality, but not vice versa.
>
>
> PHP's === operator is not, in general, an identity operator; it is a 
> "strict equality" operator, whose exact meaning depends on the type of 
> its operands.
>
> For "scalar" types, it checks the concrete type and the value: 1+1 === 
> 2, and strtoupper('hello') === 'HELLO'
>
> For arrays, the definition is applied recursively: two arrays are 
> loosely equal if all their elements are loosely equal, and strictly 
> equal if all their elements are strictly equal.
>
> Objects are really the outlier, overloading the operator to mean 
> "identity" rather than applying a strict value comparison.
>
> Example: https://3v4l.org/udOoU
>
> If we introduce some new "value type", it seems very reasonable to use 
> the same recursive definition of strict equality used for arrays.
>
>
> -- 
> Rowan Tommins
> [IMSoP]

Valid point, thank you.  Though I'm still not convinced that value object equality behaving differently from normal object equality is going to be self-evident or intuitive.

Either way, my core point still stands: Give me a way to directly control how equality works per-class, like most of our sibling languages do, and we're all set.  Problem solved.  

--Larry Garfield