<div dir="ltr">On Sat, Aug 2, 2008 at 9:28 PM, Mark Reinhold <span dir="ltr"><<a href="mailto:mr@sun.com">mr@sun.com</a>></span> wrote:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> Or just by using covariant return types, which already exist in the<br>
> language for this very purpose.  Why is everyone so keen to tear up the<br>
> language, in order to add solutions to problems that already have solutions?<br>
<br>
</div>Excellent question!</blockquote><div><br>I think most developers are way too quick to conclude that a language change is needed to solve any particular problem.  Most of us can't even begin to understand all the mountainous ramifications and repercussions, nor the incredible effort to safely rev the JLS, etc.<br>
<br>That said, I just want to address this idea of "adding solutions to problems that already have solutions."  Because among the four language features (two existing and two proposed)<br><br>- covariant return types<br>
- recursive bounds (Foo<A extends Foo<A>>)<br>- 'this' type<br>- void methods implicitly return 'this'<br></div></div><br>No two of these solve exactly the same set of problems as each other.  Each addresses at least some situations not addressed by any of the others.  So we can't effectively dismiss any of them by simply pointing to the existence of another.  And it's fair to have a discussion about what set of problems each of the latter two solves that don't have reasonable solutions already.  (But that discussion doesn't belong in this list.)<br>
<br clear="all"><br>-- <br>Kevin Bourrillion @ Google<br>internal: go/javalibraries<br><a href="http://google-collections.googlecode.com">google-collections.googlecode.com</a><br><a href="http://google-guice.googlecode.com">google-guice.googlecode.com</a><br>
<br>
</div>