<div dir="auto">Hello Brian,<div dir="auto"><br></div><div dir="auto">Thank you for your response!</div><div dir="auto"><br></div><div dir="auto">> On a historical scale, these JEPs could</div><div dir="auto">> be described as "super granular"! </div><div dir="auto">> Compare the N pattern matching JEPs so</div><div dir="auto">> far (and more coming) to a feature like</div><div dir="auto">> Lambda, which was one big JSR</div><div dir="auto">> (including the streams library). Which is</div><div dir="auto">> to say, there's always room to make the</div><div dir="auto">> glass bigger or smaller.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">> The forces that we are constantly trying</div><div dir="auto">> to balance are:</div><div dir="auto">> </div><div dir="auto">>  - Doing too much at once risks taking a</div><div dir="auto">>    long time before we deliver anything;</div><div dir="auto">> </div><div dir="auto">>  - Doing too little in one JEP means that</div><div dir="auto">>    the feature doesn't cleanly "stand alone";</div><div dir="auto">> </div><div dir="auto">>  - Each JEP has some overhead, and</div><div dir="auto">>    doing too many is impractical. In</div><div dir="auto">>    particular, having multiple JEPs for</div><div dir="auto">>    features that touch the same parts</div><div dir="auto">>    of the spec can be much more</div><div dir="auto">>    expensive, especially if they are not on</div><div dir="auto">>    the same track for when they will</div><div dir="auto">>    finalize.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">> The right balance will vary depending on</div><div dir="auto">> the feature, the degree of coupling</div><div dir="auto">> between sub-features, etc.  I'm sure that</div><div dir="auto">> we'll continue to adjust, and in some</div><div dir="auto">> cases, over-rotate. But I don't think a "let's</div><div dir="auto">> break each feature into ten JEPs, so we</div><div dir="auto">> can late-bind to which sub-features we</div><div dir="auto">> take" is a good idea in general.</div><div dir="auto"><br></div><div dir="auto">Reading this (and the other replies), it sounds like the way you all are currently doing it is the best way to approach.</div><div dir="auto"><br></div><div dir="auto">Thank you for helping me understand!</div><div dir="auto">David Alayachew</div></div>