On Mon, Apr 25, 2022 at 7:52 PM Dan Smith <daniel.sm...@oracle.com> wrote:
Yeah, I think this has to be the starting place, before we get into > whatever other model simplifications, compatible migrations, etc., might be > gained. > > The expectation for any two-types-for-one-name approach should be, I > think, that almost all types referencing the class should use the simple > name. The non-default form is for special cases only. > Whose expectation is that -- do you mean it will be what users expect? Because they might, but that's not the same as good design. The primary consideration in choosing which behavior should be the default behavior is the problem of false acceptance. i.e., If a user who did not really want this default behavior sleepwalked into it anyway, * When does that problem get discovered? Sooner, or later? Perhaps _too_ late? * Who discovers it? The same party, or someone else? * How much damage has been caused in the interim? Is any of it irreversible? These usually point pretty clearly to one of the options. But if not, the second consideration is readability: which option benefits the reader more from being called out _explicitly_? Only after that I'd move on to "which option do more users want more of the time". Sorry, that was longwinded (and possibly misplaced). So if we're considering an approach in which the reference type is used > almost all the time, we need to establish that doing so will not be > considered a "bad practice" for performance reasons. Specifically: > I don't see why this is. If there's bad performance, the users have the freedom to help themselves to the better performance any time they want to, for the minor cost of a little "sprinkling". That sounds like Valhalla success to me. Isn't it? A good test for me is this: if we asked everybody to stop saying 'int' all > the time, and prefer 'Integer' instead except in performance-critical code, > could we effectively convince them to set aside their misgivings about > performance and trust the JVM to be reasonably efficient? > Well, the thing forcing our hand in our case is the need to work within the limitations of a language with 28 years of expectations already rooted in brains. That is what says we need Foo/Foo.val. So your thought experiment is sort of a false equivalence; the same argument for Foo/Foo.val also says "but keep using int, not Integer". -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
