On 21/12/2019 00:03, Dan Smith wrote:
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).
Gotcha - thanks for the clarification
Maurizio
