New candidate JEP: 440: Record Patterns

[David Alayachew]

Hello Holo,

Thank you for your response!

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

Lot's of good points here, I see what you are saying. I personally am prone
to doing what I described above - taking 1 or 2 features from a JEP, and
then try to play with them as much as I can before moving to the next part
of the same JEP. But doesn't change the fact that my idea likely would hurt
adaptation in general. Makes sense.

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

I understand. And at this point, I think I agree. Sounds like that is more
or less what they are doing now then.

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

And I think this highlights another potential problem with splitting in
general - you have a lot of moving parts that slightly resemble each other,
so it can be easy to mix them up.

Thank you for the insight!
David Alayachew

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230318/66f20a56/attachment-0001.htm>