FTR: mapping class-like APIs to interfaces

[John Rose]

On May 18, 2017, at 8:56 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> Spurred by a conversation with some Intel colleagues, I wrote up an account

> of how we can use Java interfaces to model various kinds of APIs.


This file talks about the design of polymorphic data structures
by means of the binder pattern.  I just added to it:

  http://cr.openjdk.java.net/~jrose/panama/using-interfaces.html

There is a couple of new pages at the end about reifying binders,
via API points that ask a bound object which binder made it.

This is for use cases where you *often* don't care about how
an object is formatted (persistent memory, off-heap, POJO), but
*sometimes* you do.  (If you cared *always*, you'd use separate
types for the separate cases.  Using an interface that spans
everything allows you to write relaxed-typed code, and generic
algorithms.  Using a type variable to reify the binder type opens
the door to strongly typed generic code which can still "peek"
at the binder, if it needs to.)

This came up in today's quarterly Intel F2F, when Steve Dohrmann
was explaining his recent work on persistent collections for Java,
which is at <http://github.com/pmem/pcj>.

A surprising insight from today:  For some bindable APIs,
java.lang.String should not be used to represent text.  Instead,
it is better to use CharSequence since that is polymorphic.
That way the binder may choose to leave the characters
in the original backing storage, rather than marshaling them
eagerly into the body of a java.lang.String.  A POJO binder
can just use String directly as its preferred implementation
of CharSequence.  I wonder if that insight applies to the
strings we extract from C char* pointers?

— John