----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "John Rose" <john.r.r...@oracle.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Jeudi 21 Février 2019 14:37:31 > Objet: Re: acmp again !
>> Again pick your poison. > > The phrase "pick your poison" is misleading because it suggests all > poisons are equally fatal. And these two poisons are very, very > different. (Alcohol is a poison, and when taken recursively can indeed > be fatal, but that's not the usual outcome, nor is it usually a deterrent.) > > With the "always false" semantics, a fundamental building block of the > language has perennially astonishing semantics in situations that will > be routinely encountered by all users. (We've seen languages where the > `==` operator has semantics people can't understand; we don't want to be > them, or have to deprecate `==` in favor of `===` because the language > failed so hard the first time.) I think you are mixing acmp and ==. You can have acmp with the always false semantics and have an opt-in operator overloading mechanism so calling == on a value type is equivalent to calling equals(), but at language level, not at the VM level. This is very equivalent to what we have now with int and Integer, an == of ints is a special semantics while == of Integers is acmp. > > With the second, the performance will sometimes be mildly surprising > when some wise guy thinks he's being clever and writes some ridiculous > code, like a recursive value list. Then he'll be told to cut that out, > and life will go back to normal. Composing lambdas that are parameterized creates the kind of recursive value types the Substitutibility test will not like. > > This argument feels to me like "let's snatch defeat from the jaws of > victory." For years, we thought it was impractical that we could unify > values and references. But we are now 95% of the way there! > Substitutibility is a sound, intuitive generalization of `==` over both > refs and values. Substitutibility is not a sound generalization. But it doesn't mean the is no way to win, it's just that the Substitutibility test is not the way to win. > > While we're on the subject of fantasy, let me call attention to another > fantasy that we've been engaging in: that somehow values can remain this > "weird, off-to-the-side thing." In Q-world they were -- and when you > were writing code, you always had to be aware of whether you were > dealing with values or objects (and generic code had to learn new rules > because they might be dealing with either.) But that's not the world > we've built (thankfully!) Here, values will be a common, every day > occurrence (Optional, LocalDateTime) that all Java code will have to > deal with. (They're Objects!) We have to give people a sound, > intuitive model for dealing with the union of refs and values, because > they're going to have to deal with that. And we're almost there, as > long as we don't blow it. yes, that's exactly my point, we should not blow it by trying to have all objects operations ==, synchronized, identityHashCode, etc trying to masquerade the fact that those operations will never exactly works as their reference counterparts and that a 95% emulation is not a good idea because we want a sound and reliable model. > > I realize that we started out hyper-focused on the performance aspects > (because there'd be no point in doing values in the first place if we > didn't care about performance.) But, users will not thank us if we > routinely choose confusing semantics because its faster. Now it's time > to focus on delivering a programming model that makes users say "why > didn't you do that 20 years ago" -- and we can do that. This is winning; > let's take it. it's not about being faster, it's about not being randomly unpredictably slower. Rémi