Reference-default style

[Dan Smith]

> On Dec 19, 2019, at 5:10 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> On 19/12/2019 21:15, Dan Smith wrote:
>> Like many design patterns, (1) suffers from boilerplate overhead ((2) too, without some language help). It also risks some missed opportunities for optimization or language convenience, because the relationship between the inline and reference type is incidental. (I'd like to get a clearer picture of whether this really matters or not.)
> 
> At the last post JVMLS meeting I was a string advocate of this position. This is effectively the pattern used in the Panama memory access API, where we have public (in future sealed) interfaces backed up by inline-ready implementation classes.

To rephrase this the way I would say it: Panama has use cases that for a reference-default style.

> While I still think that there will be a lot of cases like these - Panama also needs something which is more akin to the 'programmable primitive'-half of the Valhalla glass. That is, we might want to introduce a int128 type or float16, which might be required to interop with certain system ABIs.
> 
> When you do that, you would like to have these types (e.g. int128) the *public* ones, the ones with the good names. You want users to create (flat) arrays of them, rather than oops arrays.

And: Panama has use cases for an inline-default style.

> So, as much as I like (1) I don't think we can fully get away with that?

I think you're misunderstanding (1).

The (1) story is: the language gives you inline-default inline classes; if you want to use a reference-default style, you get there via a design pattern (public superinterfaces of possibly-private inline classes).