基于价值的班级混乱 [英] Value-based Classes confusion

问题描述

我正在寻求对

我阅读不正确，还是需要更精确?

更新

伊兰(Eran)的答案很有意义(它们不再相等)，但让我移动目标:

...
assertEquals(a, b); // now, they are still equal
assertEquals(m(a, b), m(a, a)); // this will throw
assertEquals(a, b); // now, they are equal, too

让我们定义一个有趣的方法m，该方法会进行一些更改并将其再次撤消:

int m(Optional<ArrayList<String>> x, Optional<ArrayList<String>> y) {
    x.get().add("");
    int result = x.get().size() + y.get().size();
    x.get().remove(x.get().size() - 1);
    return result;
}

这是一种奇怪的方法，我知道.但是我想，它可以称为任何计算或方法调用"，不是吗?

解决方案

您可以从所引用的规范中得出操作的无效性:

如果一个程序试图将两个引用区分为基于值的类的相等值，则可能会产生不可预测的结果，无论是直接通过引用相等还是间接通过调用同步，标识哈希，序列化或其他任何其他方法身份敏感机制.在基于值的类的实例上使用此类身份敏感的操作可能会产生不可预知的影响，应避免使用此方法.

^{(重点是我的)}

修改对象是身份敏感的操作，因为它仅会影响具有用于修改的引用的具有特定标识的对象.

在调用x.get().add("");时，您正在执行一项操作，该操作可以识别x和y是否代表相同的实例，换句话说，您正在执行身份敏感操作.

我仍然希望，如果将来的JVM确实尝试替换基于值的实例，则它必须排除引用可变对象的实例，以确保兼容性.如果您执行产生Optional的操作，然后提取Optional，例如… stream. findAny().get()，如果中间操作允许用另一个在中间Optional使用时碰巧相等的对象替换元素(如果元素本身不是值类型)，那将是灾难性/不可接受的./p>

I'm seeking some clarification to the definition of Value-based Classes. I can't imagine, how is the last bullet point (6) supposed to work together with the first one

• (1) they are final and immutable (though may contain references to mutable objects)
• (6) they are freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior.

Optional is such a class.

Optional a = Optional.of(new ArrayList<String>());
Optional b = Optional.of(new ArrayList<String>());
assertEquals(a, b); // passes as `equals` delegated to the lists

b.get().add("a");

// now bite the last bullet
assertTrue(a.get().isEmpty()); // passes
assertTrue(b.get().isEmpty()); // throws

Am I reading it incorrectly, or would it need to get more precise?

Update

The answer by Eran makes sense (they are no more equal), but let me move the target:

...
assertEquals(a, b); // now, they are still equal
assertEquals(m(a, b), m(a, a)); // this will throw
assertEquals(a, b); // now, they are equal, too

Let's define a funny method m, which does some mutation and undoes it again:

int m(Optional<ArrayList<String>> x, Optional<ArrayList<String>> y) {
    x.get().add("");
    int result = x.get().size() + y.get().size();
    x.get().remove(x.get().size() - 1);
    return result;
}

It's strange method, I know. But I guess, it qualifies as "any computation or method invocation", doesn't it?

解决方案

You can derive the invalidity of your actions from the specification you’re referring to:

A program may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class, whether directly via reference equality or indirectly via an appeal to synchronization, identity hashing, serialization, or any other identity-sensitive mechanism. Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects and should be avoided.

^{(emphasis mine)}

Modifying an object is an identity-sensitive operation, as it only affects the object with the specific identity represented by the reference you are using for the modification.

When you are calling x.get().add(""); you are performing an operation that allows to recognize whether x and y represent the same instance, in other words, you are performing an identity sensitive operation.

Still, I expect that if a future JVM truly tries to substitute value based instances, it has to exclude instances referring to mutable objects, to ensure compatibility. If you perform an operation that produces an Optional followed by extracting the Optional, e.g. … stream. findAny().get(), it would be disastrous/unacceptable if the intermediate operation allowed to substitute the element with another object that happened to be equal at the point of the intermediate Optional use (if the element is not itself a value type)…

这篇关于基于价值的班级混乱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！