How to implement a record de-constructor ?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 20 Mars 2018 14:49:56
> Objet: Re: How to implement a record de-constructor ?

>> The issue is that there is no tuple in Java, so writing a de-constructor now is
>> not easy.
> Nor performant, because even though will soon have something like tuples
> (that's records), which makes it a lot easier to write, you still have
> to contend with boxing (until we have value records.)
> 
>> So we have two ways to deal with the implementation of a de-constructor:
>> 1/ internally, toString/equals or hashCode implementation of a record are
>> already using a form of de-constructor as an array of method handles
> 
> You'll recall this was the subject of my JVMLS talk last year.

i know, i had to change my talk because we had the same subject ...

> 
> But having a reasonable mechanics to translate to doesn't immediately
> give us a clue about how to write it in the language; surely we're not
> exposing method handles to the user. 

yes !

> And there are a host of
> complicating factors; composition (delegating from one matcher to
> another, such as the super matcher),

It's another reason to not have abstract record, sorry, kidding.
Allowing an explicit call to a de-constructor is more complex, again because we do not have tuples,
but we do not have to support it because for records there is always the workaround to use the getter instead of delegating to another de-constructor.

> partiality vs totality (some patterns always match on a certain type, which the compiler can reason
> about; others have dynamic conditions like "palindromic string"),
> laziness (ideally, matching Foo(var x, _) where the second component is
> ignored shouldn't cause the second component to be computed),

We are not talking about de-constructor here, right,
we have moved to how to specify a matcher, which is not exactly the same issue (despite Scala merging the two concepts).

if a de-constructor is inlined by the VM the same way getter is inlined by the VM, i.e. most of the time,
and if the de-constructor has no side effect (otherwise you have bigger problem that just a performance issue) then the VM will remove unused computation,
share common sub-expressions, etc.

> eagerness (sometimes you want a matcher to eagerly compute a snapshot, for
> purposes of data consistency), shared computations (sometimes there are
> expensive shared computations between the "does it match" calculation
> and the "extract the components" calculation, which you'd like not to
> redo, but this conflicts with laziness), inheritance of matchers,
> overriding of matchers, overloading of matchers, overload selection, and
> more.  It's a complex topic.  I propose we wait on deep-diving on this
> until we've gotten some more of the basics onto more solid footing.

i think it's useful to separate the discussion about the de-constructor from the discussion about the matcher.

Rémi