ValueType.findConstructor

[Paul Sandoz]

> On 26 Jun 2017, at 11:08, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Jun 26, 2017, at 10:46 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> Separately, in my enthusiasm i may be going down a rabbit hole regarding re-construction, arguably it’s not in the spirit of minimal. Still at some point i think we should explore this notion of a more extensible wither for value types (but it also seems application to ref/data classes too).
> 
> FTR, more on reconstrucors:  https://bugs.openjdk.java.net/browse/JDK-8182843 <https://bugs.openjdk.java.net/browse/JDK-8182843>
> 
> In that document, reconstructor is mostly a language-level concept with small
> tweaks at the VM level (to make <init> slightly less unique).  So, yes, it isn't part of MVT.
> 

Thanks.


> I think what you've found is that method handle combinators are a place where we
> can experiment with the use of reconstructors, before language changes.


Yes, in this regard i was thinking it was a subset of the extractor and pattern matching problem e.g. a theoretical source equivalent of:

  Point p = ...
  if (p match Point(x, _, z))
    return new Point(z, another_y , x)
  else
    throw new Error()


>  But that's
> not MVT either, I think.
> 

Agreed.

Paul.

> Another thing we have learned about value types is that they don't really have
> an <init> method; they have factories.  We'll *need* that concept for value types,
> and it will turn out to be *useful* for object types.  So at some point we'll have
> to coin a name that is the factory version of <init>, perhaps something like <new>,
> <instance>, <make>, <factory>, etc.
> 
> Again, none of the above is minimal, unless and except it somehow gets MVT
> out the door faster.
> 
> — John