<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Archie,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks for your reply.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">> In this case, just because (a) Java enables a coding practice you don't like doesn't mean (b) you have to tolerate it in your own organization</div><div class="gmail_default" style="font-size:small">Indeed, it can seem that way, but in reality it doesn't work well. In reality, I have to maintain code written by devs who don't work at the company anymore for a long time. They left a mess of a code behind, and in the case of undesirable language features, they did it because they could.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Kind regards,</div><div class="gmail_default" style="font-size:small">Cristian</div><div class="gmail_default" style="font-size:small"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Nov 2024 at 16:12, Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'd like to throw out a note of hope...? :)</div><div><br></div><div>I think there is a reasonable debate about whether star imports are "good" or "bad" but from the POV of language design that debate is made almost entirely moot thanks to the robust ecosystem of style checkers.</div><div><br></div><div>In other words, this is, in effect, just a policy decision that your particular organization can enforce, just like other style preferences such as whether to allow switch case fallthrough, whether to require curly braces around a one-line if/else branch, etc. If you don't like star imports, then have them cause your build to fail. Problem solved!<br></div><div><br></div><div>In this case, just because (a) Java enables a coding practice you don't like doesn't mean (b) you have to tolerate it in your own organization. The (a) and (b) are two separate issues with two separate debates and two separate resolutions.<br></div><div><br></div><div>-Archie<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 19, 2024 at 8:38 AM Pedro Lamarão <<a href="mailto:pedro.lamarao@prodist.com.br" target="_blank">pedro.lamarao@prodist.com.br</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Em ter., 19 de nov. de 2024 às 11:09, Cristian Mocanu <<a href="mailto:cvmocanu@gmail.com" target="_blank">cvmocanu@gmail.com</a>> escreveu:</div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-size:small">Knowing that code is being read many time more often than written, I don't think it makes sense to optimize writing an import by hand (which no one does anyway - the IDE writes it for us) to the detriment of introducing confusion when reading the code outside an IDE (like a GitHub PR review).</div></div></div></blockquote><div><br></div><div>Optimizing Java for GitWeb-like readers does not seem to me the way forward.</div><div>GitWeb-like products are themselves moving toward "AI powered web IDE" status.</div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div>
</blockquote></div>