Databases
StackOverflow2013
Postsdbo
POClosures in Scala vs Closures in Java
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POClosures in Scala vs Closures in Java
    primarykey
    data
    text
    <p>Some time ago Oracle decided that adding Closures to Java 8 would be an good idea. I wonder how design problems are solved there in comparison to Scala, which had closures since day one.</p> <p>Citing the <strong><em>Open Issues</em></strong> from <a href="http://www.javac.info/issues-v06a.html" rel="nofollow noreferrer">javac.info</a>:</p> <ol> <li><p><strong>Can Method Handles be used for Function Types?</strong> It isn't obvious how to make that work. One problem is that Method Handles reify type parameters, but in a way that interferes with function subtyping.</p></li> <li><p><strong>Can we get rid of the explicit declaration of "throws" type parameters?</strong> The idea would be to use disjuntive type inference whenever the declared bound is a checked exception type. This is not strictly backward compatible, but it's unlikely to break real existing code. We probably can't get rid of "throws" in the type argument, however, due to syntactic ambiguity.</p></li> <li><p><strong>Disallow @Shared on old-style loop index variables</strong></p></li> <li><p><strong>Handle interfaces like Comparator that define more than one method,</strong> all but one of which will be implemented by a method inherited from Object. The definition of "interface with a single method" should count only methods that would not be implemented by a method in Object and should count multiple methods as one if implementing one of them would implement them all. Mainly, this requires a more precise specification of what it means for an interface to have only a single abstract method.</p></li> <li><p><strong>Specify mapping from function types to interfaces:</strong> names, parameters, etc. We should fully specify the mapping from function types to system-generated interfaces precisely.</p></li> <li><p><strong>Type inference.</strong> The rules for type inference need to be augmented to accomodate the inference of exception type parameters. Similarly, the subtype relationships used by the closure conversion should be reflected as well.</p></li> <li><p><strong>Elided exception type parameters to help retrofit exception transparency.</strong> Perhaps make elided exception type parameters mean the bound. This enables retrofitting existing generic interfaces that don't have a type parameter for the exception, such as java.util.concurrent.Callable, by adding a new generic exception parameter.</p></li> <li><p><strong>How are class literals for function types formed?</strong> Is it #void().class ? If so, how does it work if object types are erased? Is it #?(?).class ?</p></li> <li><p><strong>The system class loader should dynamically generate function type interfaces.</strong> The interfaces corresponding to function types should be generated on demand by the bootstrap class loader, so they can be shared among all user code. For the prototype, we may have javac generate these interfaces so prototype-generated code can run on stock (JDK5-6) VMs.</p></li> <li><p><strong>Must the evaluation of a lambda expression produce a fresh object each time?</strong> Hopefully not. If a lambda captures no variables from an enclosing scope, for example, it can be allocated statically. Similarly, in other situations a lambda could be moved out of an inner loop if it doesn't capture any variables declared inside the loop. It would therefore be best if the specification promises nothing about the reference identity of the result of a lambda expression, so such optimizations can be done by the compiler.</p></li> </ol> <p>As far as I understand 2., 6. and 7. aren't a problem in Scala, because Scala doesn't use Checked Exceptions as some sort of "Shadow type-system" like Java.</p> <p>What about the rest?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USnicael
    1. USsoc
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POClosures in Scala vs Closures in Java
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POClosures in Scala vs Closures in Java
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POClosures in Scala vs Closures in Java
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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