<div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br>Hello Ron,<br><br>Thank you for your response!<br><br>> > We need to make sure not to forget to add the Shotgun<br>> > branch to our static initialization block. That's a<br>> > problem.<br>> <br>> Yes, but is it a big one? How often is it encountered and<br>> how hard is it to detect and solve?<br><br>Lol, let me link you again to my post about Data-Oriented Programming.<br><br><a href="https://mail.openjdk.org/pipermail/amber-dev/2022-September/007456.html">https://mail.openjdk.org/pipermail/amber-dev/2022-September/007456.html</a><br><br>My biggest pain point from there by far was not being able to keep track of all of my states attributes as they morphed due to changing requirements. I went into great detail talking about exactly how big of a pain point it was in my side. Several people were able to sympathize with me as well.<br><br>> Having the language solve every problem that the language<br>> can solve is one approach to language design, but it<br>> rarely yields popular languages. Such languages tend to<br>> grow quickly.<br>> <br>> The challenge of language design is exercising judgment<br>> in picking which problems are worth addressing. Every<br>> feature needs to “carry its weight”: the magnitude of the<br>> problem it solves needs to be bigger than the complexity<br>> it adds to the language. Much if not most of the time we<br>> spend thinking about features is spent on answering the<br>> question: is the problem big enough to justify<br>> complicating the language (or even spending time thinking<br>> about a solution)? That’s also where most ideas,<br>> including those that are raised internally, are dropped;<br>> yes, they solve a problem, but not one that’s big enough<br>> to justify a language change.<br><br><br>Agreed. That's why I started this entire thing off by talking about what was bothering me and seeing if anyone else could relate. My claim was based on a faulty premise, but once the foundation of that premise was corrected and reoriented, I think I have pointed out a significant pain point in the language.<br><br>> Maybe there’s a way to extend definite assignment in a<br>> way that covers sufficiently many more interesting cases<br>> that aren’t currently covered without adding too much<br>> complexity, but my gut instinct is that the cost/benefit<br>> here is more questionable than other features we’re<br>> working on, and so isn’t a high priority. In other words,<br>> given the likely-non-trivial nature of a feature that<br>> would cover this use case, the magnitude of the problem,<br>> as presented, is not big enough to merit immediate<br>> attention<br><br>I'm definitely willing to accept that this feature just isn't a top priority compared to deconstruction patterns or something similar.<br><br>But I feel like once an accurate picture of the level of effort has been painted, that'll be when this question can be answered.<br><br>And I should emphasize -- any successful attempt to improve definite assignment will have a massive reach because definite assignment is EVERYWHERE in Java. It bleeds into practically every line of code we ever write in Java. Even a small improvement, that only moves the ball forward a few inches, will have a huge benefit. It becomes a question of the costs.<br><br>> (although sometimes we need to address a<br>> smaller problem when we discover it stands in the way of<br>> addressing a bigger problem).<br><br>I see what you mean. I am curious if the world of lazy loading would benefit from this.<br><br>> But that’s just my opinion. Maybe when others return from<br>> their vacation they would want to offer a different<br>> perspective.<br><br>Yes, would love to hear more perspectives on this topic. You and I have had plenty to say, but my primary goal was to see if anyone felt similarly.<br><br>Thank you for your time and help!<br>David Alayachew<br></div><br></div>