Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><em>1) Can Method Handles be used for Function Types?</em></p> <p>Scala targets JDK 5 and 6 which don't have method handles, so it hasn't tried to deal with that issue yet.</p> <p><em>2) Can we get rid of the explicit declaration of "throws" type parameters?</em></p> <p>Scala doesn't have checked exceptions.</p> <p><em>3) Disallow @Shared on old-style loop index variables.</em></p> <p>Scala doesn't have loop index variables. Still, the same idea can be expressed with a certain kind of while loop . Scala's semantics are pretty standard here. Symbols bindings are captured and if the symbol happens to map to a mutable reference cell then on your own head be it.</p> <p><em>4) Handle interfaces like Comparator that define more than one method all but one of which come from Object</em></p> <p>Scala users tend to use functions (or implicit functions) to coerce functions of the right type to an interface. e.g.</p> <pre><code>[implicit] def toComparator[A](f : (A, A) =&gt; Int) = new Comparator[A] { def compare(x : A, y : A) = f(x, y) } </code></pre> <p><em>5) Specify mapping from function types to interfaces:</em></p> <p>Scala's standard library includes FuncitonN traits for 0 &lt;= N &lt;= 22 and the spec says that function literals create instances of those traits</p> <p><em>6) Type inference. The rules for type inference need to be augmented to accomodate the inference of exception type parameters.</em></p> <p>Since Scala doesn't have checked exceptions it can punt on this whole issue</p> <p><em>7) Elided exception type parameters to help retrofit exception transparency.</em></p> <p>Same deal, no checked exceptions.</p> <p><em>8) How are class literals for function types formed? Is it #void().class ? If so, how does it work if object types are erased? Is it #?(?).class ?</em></p> <pre><code>classOf[A =&gt; B] //or, equivalently, classOf[Function1[A,B]] </code></pre> <p>Type erasure is type erasure. The above literals produce scala.lang.Function1 regardless of the choice for A and B. If you prefer, you can write </p> <pre><code>classOf[ _ =&gt; _ ] // or classOf[Function1[ _,_ ]] </code></pre> <p><em>9) The system class loader should dynamically generate function type interfaces.</em></p> <p>Scala arbitrarily limits the number of arguments to be at most 22 so that it doesn't have to generate the FunctionN classes dynamically.</p> <p><em>10) Must the evaluation of a lambda expression produce a fresh object each time?</em></p> <p>The Scala specification does not say that it must. But as of 2.8.1 the the compiler does not optimizes the case where a lambda does not capture anything from its environment. I haven't tested with 2.9.0 yet.</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