On 6/7/2021 11:13 AM, Dan Smith wrote:
On Jun 5, 2021, at 9:21 AM, Brian Goetz <brian.go...@oracle.com> wrote:
Rampdown is next week; time is fleeting.
I think the path of adding Objects::newIdentity in 17 seems the best
alternative. If there are objections, make them now.
I still think that's a second-best option. Utility classes were all the rage 20
years ago. Default/static interface methods have largely replaced them.
But this _is_ a utility. The user can always get this behavior by (say)
`new Object(){}`, or any number of other means. The existence of an API
point here is a convenience, and one primarily for readability of code
(so its clear that the reason someone is creating an object in a weird
way is to get the identity.)
To help illustrate this point, consider the other end of the coin.
Suppose our implementation is:
interface IdentityObject {
static newIdentity() { return new PlaceholderIdentityClass(); }
}
Should PlaceholderIdentityClass be public? I argue that not only is it
not beneficial to expose it, but it is actively a mistake to expose it.
Because the name does not correspond to any useful user-observable
semantics, and might even inspire bad assumptions that _all_
identity-only instances are of this type. Defining a public type (in
java.lang, no less) for something that is useless to the user is
actively harmful, because people are going to wonder what to use it for
(or not use it for.) The same argument applies, at varying degrees, to
where you place this method.
Aesthetics aside, in the Objects approach, what's the return type? It would
have to be Object. But then we're going to want to turn around and make it
IdentityObject—a binary incompatible change.
Maybe. We've talked about whether it makes more sense to erase
IdentityObject to Object, to allow compatible migration of existing
identity-assuming code. We've also talked about finally allowing user
control over bridge generation, in which case we change it to
IdentityObject and have an Object bridge for binary compatibility.
