----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "daniel smith" <daniel.sm...@oracle.com>, "valhalla-spec-experts" > <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 16 Juin 2021 23:50:35 > Objet: Re: Making Object abstract
> On Jun 2, 2021, at 7:57 AM, Brian Goetz <brian.go...@oracle.com> wrote: >> >> A minor bikeshed comment: We're asking users to change their `new Object()` >> to >> `IdentityObject.newIdentity()`, and they may ask "why do I have to say >> 'Identity' twice"? (And by ask, I mean grumble, because we're already asking >> them to change their working code.) >> >> After a few minutes of thought, I think it might be a better fit to put this >> at >> Objects::newIdentity. The methods in Objects are conveniences that users >> could >> write themselves, which this basically is -- there's nothing special about >> this >> method, other than having a preferred alternative to `new Object()` which >> users >> will understand. So parking this where the Object conveniences go seems >> slightly lower friction. > > I think this is OK. > > As a stretch move, I think we can even retro-upgrade > the type checking of Objects::newIdentity with type > variable trickery, when IdentityObject becomes real. > > Please see: > > https://bugs.openjdk.java.net/secure/attachment/95170/Foo.java > https://bugs.openjdk.java.net/browse/JDK-8268919 I wonder if a simple way to avoid to allow any Ts if to allow to specify an intersection type as parameter type and/or return type of methods (we have 'var' inside the body) so instead of public static <T extends Object & IdentityObject> T newIdentity() { we can write public static Object & IdentityObject newIdentity() { This requires a grammar change but it's exactly the type we want. > > — John Rémi
