How to implement a record de-constructor ?
brian.goetz at oracle.com
Tue Mar 20 13:49:56 UTC 2018
> 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.
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. And there are a host of
complicating factors; composition (delegating from one matcher to
another, such as the super matcher), 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), 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.
More information about the amber-spec-observers