Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<ol> <li><p>Scala has had good stuff added for quite a while, but as it gains popularity it will get increasingly more stable. People who were around before 2.8 had much more leverage on modifying the language than people nowdays -- both because they represented a bigger percentage of users, and because the language was more flexible.</p> <p>Take, for instance, your issue with erasure. As a 2.0 user you'd have a way bigger chance of getting something done about it than you have now. In fact, the impact that would have in compatibility is pretty much a guarantee that it won't happen anymore, unless Java leads.</p></li> <li><p>You come from a scripting language. Scripting languages are very much concerned with I/O, because that's their butter and bread. For Scala, any serious I/O is simply relegated to Java libraries -- that's kind of the point of having Scala be compatible with Java, after all.</p> <p>Furthermore, your characterization of 4662 is, actually, completely wrong. It was not broken <em>at all</em>, though a change in behavior made arguably incorrect code work again. This is 4662 in a nutshell:</p> <pre><code>val source = scala.io.Source.fromFile(new java.io.File("test1.file")) use(source) val lines = source.getLines </code></pre> <p>Since <code>source</code> is an <code>Iterator</code>, it is gone once you use it. It was a coincidence that you could reuse it after calling <code>toString</code> on it, not an intrinsic guarantee.</p></li> <li><p>Type erasure is not so bad. In fact, it is a sign of bad design if it gets much in the way -- you are not supposed to check what the type of something is, but to call methods on it and let <em>it</em> handle itself. Not to say it isn't annoying at times, but not so badly. Alas, it is a fundamental choice in having seamlessly compatibility with Java, and it was very consciously made. I don't see Scala leading the way out of it.</p> <p>One of the new languages that promise to get rid of erasure, and maintain compatibility with Java, is Ceylon. If Ceylon manages that, and I'm firmly in the doubters camp, then Scala could follow.</p> <p>Also, on a recent discussion of closures for Java 8 indicated the possibility that something might be done about erasure. If that turns out to be true, then Scala could cash in as well.</p></li> </ol> <p>As for the question, I agree that these types could be inferred. I'm not sure anyone is doing something with default parameters, however -- priorities for the moment lie elsewhere.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload