Замыкания в Scala против замыканий в Java
Некоторое время назад Oracle решила, что добавление замыканий в Java 8 было бы хорошей идеей. Интересно, как там решаются проблемы проектирования по сравнению со Scala, закрытие которой было закрыто с первого дня.
Ссылаясь на Открытые проблемы из javac.info : Непонятно, как это сделать. Одна из проблем заключается в том, что Method Handles реифицируют параметры типа, но таким образом, который мешает выделению подтипов функций.
Можем ли мы избавиться от явного объявления параметров типа throws? Идея состоит в том, чтобы использовать вывод дизъюнктивного типа всякий раз, когда объявленная граница является проверенным типом исключения. Это не совсем обратная совместимость, но вряд ли нарушит существующий код. Однако мы, вероятно, не сможем избавиться от «бросков» в аргументе типа из-за синтаксической двусмысленности.
Запретить @Shared для переменных индекса цикла старого стиля
Обрабатывать интерфейсы, такие как Comparator, которые определяют более одного метода, все, кроме одного, будут реализованы методом, унаследованным от Object. Определение «интерфейс с одним методом» должно учитывать только те методы, которые не могут быть реализованы методом в Object, и должно учитывать несколько методов как один, если реализация одного из них будет реализовывать их все. В основном это требует более точной спецификации того, что означает наличие в интерфейсе только одного абстрактного метода.
Укажите отображение типов функций на интерфейсы: имена, параметры и т. Д. Мы должны полностью указать отображение типов функций на интерфейсы, генерируемые системой.
Вывод типа. Правила вывода типа необходимо дополнить, чтобы приспособить вывод параметров типа исключения. Точно так же должны быть отражены отношения подтипов, используемые преобразованием замыкания.
Исключенные параметры типа исключения, чтобы помочь модифицировать прозрачность исключения. Возможно, параметры типа исключенного исключения означают границу. Это позволяет модифицировать существующие универсальные интерфейсы, которые не имеют параметра типа для исключения, например java.util.concurrent.Callable, путем добавления нового универсального параметра исключения.
Как формируются литералы классов для типов функций? Это #void (). Class? Если да, то как это работает, если типы объектов стираются? Это #? (?). Class?
Загрузчик системного класса должен динамически генерировать интерфейсы типов функций. Интерфейсы, соответствующие типам функций, должны генерироваться по запросу загрузчиком классов начальной загрузки, чтобы их можно было использовать для всего пользовательского кода. В качестве прототипа мы можем использовать javac для создания этих интерфейсов, чтобы код, созданный прототипом, мог работать на стандартных (JDK5-6) виртуальных машинах.
Должна ли оценка лямбда-выражения каждый раз создавать новый объект? Надеюсь, что нет. Например, если лямбда не захватывает переменные из охватывающей области видимости, она может быть выделена статически. Точно так же в других ситуациях лямбда может быть перемещена из внутреннего цикла, если она не захватывает никакие переменные, объявленные внутри цикла. Поэтому было бы лучше, если бы спецификация ничего не обещала об эталонной идентичности результата лямбда-выражения, чтобы такая оптимизация могла быть выполнена компилятором.
Насколько я понимаю, 2., 6. и 7. aren ' Это проблема в Scala, потому что Scala не использует проверенные исключения в качестве некой «теневой системы типов», такой как Java.
А как насчет остальных?