Вопросы Теги

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

Каково текущее состояние спецификации для закрытия 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. т.е. закрытия и методы interchangeble оперативно?
    Следующий синтаксис был бы позволен?

    // 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. Так как закрытия были бы пространство кода доступа, как отражение будет, использование закрытия замедлило бы производительность программы? В противном случае это означало бы, то отражение будет ускорено путем заимствования усовершенствований, сделанных в "технологии закрытия"?

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

Позвольте мне запросить Вас сфокусироваться на сути вопросов, не на каких-либо ошибочных/опечатках/пропавших без вести ключевых словах синтаксиса в примере кода. Любые опечатки/ошибки, исправьте их для меня.Спасибо.

11
задан Nissa 25 October 2016 в 20:33
поделиться

2 ответа

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

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

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

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

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

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

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

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

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

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

1
ответ дан 3 December 2019 в 08:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: