New candidate JEP: 440: Record Patterns

[David Alayachew]

Hello Brian,

Thank you for your response!

> On a historical scale, these JEPs could
> be described as "super granular"!
> Compare the N pattern matching JEPs so
> far (and more coming) to a feature like
> Lambda, which was one big JSR
> (including the streams library). Which is
> to say, there's always room to make the
> glass bigger or smaller.

I see what you mean. Even now, I'm still learning all the different ways
that Streams and Lambdas and type inference play with each other. In
comparison, these JEP's are fairly standalone and easy enough to reason
about.

> The forces that we are constantly trying
> to balance are:
>
>  - Doing too much at once risks taking a
>    long time before we deliver anything;
>
>  - Doing too little in one JEP means that
>    the feature doesn't cleanly "stand alone";
>
>  - Each JEP has some overhead, and
>    doing too many is impractical. In
>    particular, having multiple JEPs for
>    features that touch the same parts
>    of the spec can be much more
>    expensive, especially if they are not on
>    the same track for when they will
>    finalize.

Thanks for explaining the thought process behind this. And I am sure that
my idea unbalances the harmony of what you mentioned above. I was more
approaching from the direction that maybe having things unbalanced a bit
might be worth it because of the improved feedback. But reading yours and
Holo's replies have shown that my idea likely wouldn't bring the improved
feedback I was looking for.

> The right balance will vary depending on
> the feature, the degree of coupling
> between sub-features, etc.  I'm sure that
> we'll continue to adjust, and in some
> cases, over-rotate. But I don't think a "let's
> break each feature into ten JEPs, so we
> can late-bind to which sub-features we
> take" is a good idea in general.

Reading this (and the other replies), it sounds like the way you all are
currently doing it is the best way to approach.

Thank you for helping me understand!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230318/3c5d0d0b/attachment.htm>