New candidate JEP: 440: Record Patterns

[David Alayachew]

Hello Amber Dev Team,

I'm very happy to see this feature is almost ready to release for General
Availability. Java 21 can't arrive soon enough.

Looking at the link, I have a few comments. I'll make each comment a
separate thread to facilitate discussion.

I see that record patterns in for each loop are being dropped, which makes
sense. I definitely agree with this decision.

I am curious though - what are your thoughts on having multiple, super
granular JEP's that only do one thing, and then work on several of them at
once? Is the current form more preferred?

I ask this because there have been a couple of things being dropped from
JEP's 440 and 441. And to be clear, this is a very good thing - deferring
the edge cases for later when you might have a better answer sounds like
the same conservative approach that allowed the language to avoid potholes
by being a last mover. I think that this is a wise mindset.

I am just curious if breaking JEP's up into a bunch of super granular
mini-JEP's might actually facilitate this sort of last mover mindset. There
are some things that are obviously right and can be comfortably pushed to
GA after a minimal number of iterations (if any), while others may require
some reworking and several iterations.

On top of that, there are some issues that better come to light when you
have one part of a major feature in GA, but another part still being
iterated on in preview. Being able to send out the pieces like that may
even result in better solutions that would be harder to discover when
everything is in preview all at once.

Furthermore, I think it would allow the developers looking in to be able to
better see what is and isn't enabled by certain JEP's. While I understand
that we don't need to cater to those who won't take the effort to read, the
simple reality is that there are plenty of devs who see the giant wall of
text that is the JEP's, then just skip to the code examples and start
commenting. Taking on the extra overhead may enable the community to have
better informed commentary, and allow us to discover pain points that might
get hidden in the details with the normal sized JEP's we are all used to.
Hidden is definitely the wrong word to use here, but I want to communicate
the perspective of those who act like how I mentioned immediately above

That said, I admit - this likely involves a lot more overhead for the team.
I don't have any sort of picture of how much, but I readily concede that
this can easily be a dealbreaker.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230318/4e95948e/attachment.htm>