Foo / Foo.ref is a backward default; should be Foo.val / Foo

[Dan Smith]

On Apr 25, 2022, at 8:20 PM, Kevin Bourrillion <kevinb at google.com<mailto:kevinb at google.com>> wrote:

On Mon, Apr 25, 2022 at 7:52 PM Dan Smith <daniel.smith at oracle.com<mailto:daniel.smith at 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.

It's how I interpret our requirements, I guess?

The vision of B3 is "user-defined primitives": that someone can define in a library a type that can be used interchangeably with the existing built-in primitive types. (We can debate whether "primitive" is the right word here, but the concept persists under whatever naming scheme.)

If the expectation is that a typical programmer is going to look over their menu of types and choose between 'int', 'long', or 'Integer128.val', I think we've heavily biased them against the third one. The syntactic overhead is just too much.

Whereas if we're saying "just use plain reference type 'Integer128', it'll usually be fine", that's probably something we can sell (if we can deliver on "usually fine"), even though the menu will be more like 'Integer', 'Long', and 'Integer128'.

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?

I think our success will come from widespread high-performance use of these classes. Like how 'int' works. If the L types are not "high-performance" (a subjective measure, I know), and the Q types are pain to use, I worry that won't be perceived as successful. (Either "Valhalla is a pain to use" or "Valhalla rarely delivers the promised performance".)

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.

I'm thinking about this test more from a clean slate perspective, I think: rephrased, in a new language (something like Kotlin, say), could we leave out 'int', and convince people to do everything with 'Integer', or in performance-sensitive cases say 'Integer.val'? Would that language be perceived as worse (on either performance or syntactic grounds) than Java?