New candidate JEP: 440: Record Patterns

[Holo The Sage Wolf]

Hello David,

There are several problems I can see from using mini-JEP for a new language
feature, the biggest one of them is that counter-intuitively I believe it
will slow down adaptation and slow down user-feedback loop.

If, for example, we separate in JEP 440 the "base" instanceof-pattern, the
nested-pattern and the generic-pattern, a lot of people will either feel
unsatisfied from the JEPs and will just wait (and in this case, by the time
they will give feedback, the "base"-pattern will already be late in the
releasing cycle) or they will use hacks to implement the missing language
features (and in this case, their feedback does not reflect the "meat" of
the JEP),I am definitely guilty for doing this.

I think that mini-JEPs can work in enhancements to existing features (I am
aware of the irony), e.g. for-pattern that was dropped, generalized matcher
(which is being discussed in the expert-mailing group), parenthesized
patterns as you discussed in a different thread.

Even with the very big JEPs of Record patterns and Pattern Matching for
switch I definitely feel like people accidently give feedback to the wrong
JEP between the 2 a lot.


On Sat, Mar 18, 2023 at 8:06 AM David Alayachew <davidalayachew at gmail.com>
wrote:

> 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
>
>

-- 
Holo The Wise Wolf Of Yoitsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230318/33817b12/attachment.htm>