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

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

11 голосов
/ 07 февраля 2010

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

  1. В предложенной спецификации закрытия 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);
}

  2. Будут ли нормальные методы рассматриваться как неанонимные замыкания?
    Так возможен ли следующий синтаксис? 

    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
  }
}

  3. То есть функционально взаимозаменяемы затворы и методы?
    Будет ли разрешен следующий синтаксис? 

    // 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));
}

  4. Как мы сможем указать тип замыкания в интерфейсе?
    Можем ли мы сделать следующее, эффективно объявив окончательную / постоянную ссылку на методы. 

    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
  };
}

  5. Поскольку замыкания будут обращаться к пространству кода, так же как и отражение, будет ли использование замыканий замедлять производительность программы? Если нет, то будет ли это означать, что рефлексия будет ускорена за счет заимствования авансов, достигнутых в «технологии закрытия»?

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

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

Ответы [ 2 ]

12 голосов
/ 07 февраля 2010

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

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

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

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

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

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

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

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

Для части 5, я подозреваю, что производительность будет аналогична внутренним классам.

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

...