> On Dec 19, 2019, at 5:10 PM, Maurizio Cimadamore > <maurizio.cimadam...@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).
