amber-docs VS jdk-mc

Record patterns are one step on the path to general pattern matching utility. The bigger building block is general deconstructors. I recommend reading Functional Transformation of Immutable Objects by Brian Goetz. The idea of "withers" shown there requires deconstructors:

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

This is the vague plan.

You may be joking but...

Here is the much more detailed version: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

This kind of pattern matching is discussed in the design notes: https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md

True, but that only pushes the question of value down the line.

I'm curious about lenses because Java did have a serious problem that required a solution: working with "simple" data correctly was difficult. The chosen solution was ADTs, so we did buy into that. But the approach being explored for transforming records (https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...) only works one level at a time rather than for an entire path. So I wonder how valuable it would be to have a solution for paths. If the answer is that it's mostly valuable for an approach we haven't bought into yet, then we might not need to consider it just yet.

Just a heads up, something like that spread operator is actually coming sooner or later to java: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Pattern matching (for records) is already a preview feature.

jdk-mc has nashorn and javax forward-ported into Java 15, though it also has a lot of other Minecraft-specific changes and also ignores most permissions errors.

Great, now I have to merge this with jdk-mc. I'd been holding off on what will likely be a very painful merge.

On a scale from 1 to 10, with 6 being the highest, how awful is this to you: https://github.com/ameisen/jdk-mc