3 ms·
"==" considered harmful? :) Maybe we should explicitly say O.referenceEquals(O2) or O.fullDepthEquals(O2) or O.itemsReferencesEqualInAnyOrder(O2). etc.
by quickthrower2 4y ago
"==" considered harmful? :)
Maybe we should explicitly say O.referenceEquals(O2) or O.fullDepthEquals(O2) or O.itemsReferencesEqualInAnyOrder(O2). etc.
- marcosdumay 4y agoWhy would one care about reference equality of anything in Javascript? It's not like memory addresses are a concept on that language.
- UK-Al05 4y agoReference equals doesn't make sense for a value object anyway.
- quickthrower2 4y agoUnless you are using immutable objects. Then efficient equality check is referenceEquals() || deepEquals()
- nine_k 4y ago1 is an immutable object, and in languages such as Java or C++ it's not a reference-type object. You meant heap-allocated immutable objects, like some kind of a Haskell list, or maybe small stack-allocated immutable objects, like a tuple.
- int_19h 4y agoThat should be in the guts of the implementation of == for value types, not something exposed outside of it.
- quickthrower2 4y agoYes I agree, in Haskell it is derived, for example.
- lmkg 4y agoCommon Lisp does this. EQL means reference-equals, and EQUAL means value-equals (recursive). If you need to custom behavior, then EQUALP is a generic function that can be overridden for your data types. ...and then it keeps going. EQ differs from EQL only by having undefined behavior on integers and characters, because that gives implementations the freedom to box those datatypes or not while still guaranteeing that EQ is always a pointer-comparison. And = is numeric equality, which is different than value equality because 0.0 is = to -0.0 but not EQL to it.
- moonchild 4y ago> If you need to custom behavior, then EQUALP is a generic function that can be overridden for your data types. EQUALP is not a generic function. > EQ differs from EQL only by having undefined behavior on integers and characters, because that gives implementations the freedom to box those datatypes or not while still guaranteeing that EQ is always a pointer-comparison The distinction is more subtle than that. EQ could have been defined to have consistent behaviour for numbers and characters, such that eg (eq x x) would always be true (but (eq x y) would not be implied by (eql x y)), but it was not. Such a definition would have been easier to understand, and would not have prevented implementations from using efficient immediate representations for numbers and characters. > = is numeric equality, which is different than value equality because 0.0 is = to -0.0 but not EQL to it Only on implementations which distinguish negative zero. The standard explicitly calls this out. A better example is 3 vs 3.0.
- int_19h 4y agoIn Python, (a == b) is always value equality, and (a is b) is always reference equality. The only unfortunate aspect is that == is defined for all types - IMO it really should default to throw, and only classes for which value equality makes sense should define it.
- deleted 4y ago[deleted]
- nine_k 4y agoDefaulting to False is the next best thing. Evil starts when objects of different types are considered value-equal under some circumstances. Python does not have this, with the benign exception of promoting ints to floats, so that 1 == 1.0.
- int_19h 4y agoIt doesn't quite default to False, since every object is still equal to itself. The consequence is that people use == for identity equality sometimes - often not fully intentionally, e.g. by using objects as dict keys directly without using id(). But, conversely, a design that doesn't allow == for everything means that value-equality and reference-equality dicts would have to be different, as well.