4 ms·

Ya. Hindsight's 20/20. I've half expected the Java/JVM team to change Object to extend a new "NakedObject", and implementing new interfaces Equalable, Hashable

Ya. Hindsight's 20/20. I've half expected the Java/JVM team to change Object to extend a new "NakedObject", and implementing new interfaces Equalable, Hashable, Finalizable, and Waitable. (Current interface Clonable is a goof, so maybe deprecate it and replace with Copyable.) Then "NakedObject" would only need getClass method, right? Then values and records could also extend NakedObject, right? Then equals and clone/copy could be generic, right? -- Alternately, maybe prevent the gotchas with missing equals, hashCode, and toString by having the runtime autogenerate something reasonable.

masklinn 2y ago
> maybe prevent the gotchas with missing equals, hashCode, and toString There's no actual gotcha to them not existing. It works perfectly fine in haskell or rust for instance. Although it's not a fundamentally useful change to make objects for which a sensible equals/hashcode is trivial not have it, and still have it for objects for which it's not. So without the ability to reach back and remove those properties being universal I fail to see what the point would be.
layer8 2y ago
This would break the invariant that x instanceof Object is true for all non-primitive values x. This assumption is baked into too much code and too many APIs. For example, you couldn’t add a NakedObject-but-not-Object to a java.util.List, because what Object would List::get(index) then return for it? (Note that the List’s type parameter doesn’t exist at runtime and may also not exist at compile time.)
- masklinn 2y ago
  java.util.List can't deal with value types in the first place, they have to be boxed. I would assume "naked objects" would have to be bridged similarly. Either that, or java would have to gain some form of partial reification such that collections would be able to work with unboxed values. IIRC project valhalla includes the latter, or it did at one point.

masklinn 2y ago

> maybe prevent the gotchas with missing equals, hashCode, and toString There's no actual gotcha to them not existing. It works perfectly fine in haskell or rust for instance. Although it's not a fundamentally useful change to make objects for which a sensible equals/hashcode is trivial not have it, and still have it for objects for which it's not. So without the ability to reach back and remove those properties being universal I fail to see what the point would be.

layer8 2y ago

This would break the invariant that x instanceof Object is true for all non-primitive values x. This assumption is baked into too much code and too many APIs. For example, you couldn’t add a NakedObject-but-not-Object to a java.util.List, because what Object would List::get(index) then return for it? (Note that the List’s type parameter doesn’t exist at runtime and may also not exist at compile time.)

masklinn 2y ago
java.util.List can't deal with value types in the first place, they have to be boxed. I would assume "naked objects" would have to be bridged similarly. Either that, or java would have to gain some form of partial reification such that collections would be able to work with unboxed values. IIRC project valhalla includes the latter, or it did at one point.