Re: [RFC] Data Classes

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