Подтвердить что ты не робот

Типы закрытия Java, переменные, массивы и коллекции

Каково текущее состояние спецификации для закрытия Java?

  • В предлагаемой спецификации закрытия Java мы могли бы создать массив или коллекцию закрытий?
    Если да, возможно ли это синтаксис?

    {int x, int y => boolean b}[] comparisonSwitch = {
      {int i, int j => return i>j},
      {int i, int j => return j<i},
      {int i, int j => return j==i}
    }
    
    boolean compare(int acase, int a, int b){
      return comparisonSwitch[acase].invoke(a,b);
    }
    
  • Можно ли считать обычные методы не анонимными закрытием?
    Можно ли использовать следующий синтаксис?

    public class Asdf
    {
      public boolean gt(int x, int y){
        return x>y;
      }
      public boolean lt(int x, int y){
        return x<y;
      }
      public boolean eq(int x, int y){
        return x==y;
      }
    
      {int x, int y => boolean b} GT = gt;
      {int x, int y => boolean b}[] comparisonSwitch = {
        gt, lt, eq
      }
    }
    
  • т.е. операторы замыкания и методы взаимозаменяемы?
    Можно ли разрешить следующий синтаксис?

    // declare a method that has a closure type as an argument
    void closurator( {String s => int a} findlen ){
      // do whatever
    }
    String s = "hello";
    void useClosurator(){
      // invoke the method by supplying a non-anonymous method
      // of an object
      closurator(s.indexOf(String ss));
    }
    
  • Как мы можем указать тип замыкания в интерфейсе?
    Можем ли мы сделать следующее, эффективно объявив окончательную/постоянную ссылку на методы.

    interface Closuration
    {
      public class Asdf
      {
        static public boolean gt(int x, int y){
          return x>y;
        }
        static public boolean lt(int x, int y){
          return x<y;
        }
        static public boolean eq(int x, int y){
          return x==y;
        }
      }
    
      {int x, int y => boolean b}[] comparisonSwitch = {
        Asdf.gt, Asdf.lt, Asdf.eq
      };
    }
    
  • Так как закрытие будет доступ к кодовому пространству, так же как и отражение, использование закрытия замедляет производительность программы? Если нет, значит ли это, что отражение будет ускорено за счет заимствований, достигнутых в "технологии закрытия"?

Вставить новый вопрос: На самом деле, будет ли код замыкания частью кодового пространства или переменной кучи, потому что я предсказываю, что код закрытия будет восприимчивым к стиранию сборки мусора, правильно?

Могу я попросить вас сосредоточиться на сути вопросов, а не на каких-либо синтаксических ошибках/опечатках/недостающих ключевых словах в примере кода. Любые опечатки/ошибки, пожалуйста, исправьте их для меня. Спасибо.

4b9b3361

Ответ 1

Вы спрашиваете о работе закрытия JDK7, поэтому ссылки на javac.info не актуальны. Этот сайт посвящен уже завершенному проекту закрытия openjdk, в котором показано, как добавить прозрачные закрытия к Java - прозрачности в смысле удовлетворения принципа Тенентной Корреспонденции и описано примерно в мой блог.

Усилия для JKD7 организованы в рамках openjdk lambda project. Спецификация проходит быструю эволюцию, поэтому любые ответы являются предварительными. Как отметил Том Хоутин, вот последняя спецификация проекта.

Прежде чем отвечать на ваши конкретные вопросы, стоит заметить, что Java имеет отдельные пространства имен для переменных и методов. Следовательно, существует, вероятно, синтаксическое различие между вызовом метода и вызовом переменной типа функции (в языке С#, делегат). Точно так же маловероятно, что вы сможете ссылаться на метод, просто называя его, как вы хотели бы обратиться к полю.

Чтобы ответить на ваши вопросы:

  • Это не предлагаемый синтаксис для типа функции. Устраняя эту проблему, вы задаетесь вопросом, будет ли законным иметь массив типа функции. В текущем проекте спецификации указывается, что ответ "да", но известные стратегии реализации приведут к созданию дыры в системе типов, если "массив типа функции" каким-то образом не разрешен. Проект спецификации тщательно избегает обсуждения стратегий реализации. Возможно, изменения VM спецификации могут быть сделаны для решения этих проблем. Если я должен был догадаться, я подозреваю, что ответ на ваш вопрос будет "нет". Тем не менее, вы сможете добиться такого же эффекта, используя java.util.List вместо массива. Учитывая, что отдельная монета проекта рассматривает возможность добавления Collection литералов и операций индексирования для List, это, вероятно, будет столь же синтаксически удобным.
  • Вам интересно, будете ли вы создавать функциональнозначное выражение, назвав метод. Поскольку (среди других причин) методы и переменные появляются в разных пространствах имен в Java, ответ, вероятно, нет. Тем не менее, возможно, что спецификация будет расширена с помощью специального синтаксиса для запроса того, чтобы имя метода рассматривалось как выражение, зависящее от функции. См. Раздел Ссылки на методы в документе Закрытие для Java (v0.6a) для одного способа, который можно было бы рассмотреть, используя синтаксис, предложенный Стивеном Колборн. Это еще не в проекте проекта lambda.
  • См. ответ на (2).
  • См. ответ на (2).
  • Вы обеспокоены производительностью. Короче говоря, маловероятно, что замыкания будут реализованы с помощью любых методов, из-за которых их гораздо дороже, чем метод. Для повышения производительности нет изменений в VM, хотя они могут быть хорошей идеей по другим причинам (см. Ответ на 1). См. страница проекта Closures для указателя на прототип BGGA, более амбициозной спецификации закрытия, которая работает на складе jdk5/jdk6 и чьи производительность, которую вы можете измерить.

Ответ 2

Закрытия в JDK7 на данный момент неточны. В презентации Devoxx используемые примеры были очень похожи на FCM закрывает предложение.

Предполагая, что спецификация используется в JDK7, я думаю, что ответ на части 2, 3 и 4 вашего вопроса - да (хотя я вполне мог ошибаться).

Для части 1 - я думаю, что должно быть возможно иметь массивы, поскольку литералы метода присваиваются объектам метода.

Для части 5 я бы предположил, что производительность будет похожа на внутренние классы.

Извините, я немного расплывчатый - надеюсь, это немного поможет. Вероятно, еще рано отвечать на ваши вопросы с уверенностью.