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
