Сложность текущего предложения Lambda в Java 7? (Август 2010)

Я не следил за процессом и развитием лямбда-выражения Java 7. предложение, я даже не уверен, какова последняя формулировка предложения. Считайте это высказыванием / мнением, а не утверждением истины. Также, Я давно не использовал Java, поэтому синтаксис может быть ржавым и местами некорректно.

Во-первых, что такое лямбда-выражения для языка Java? Синтаксический сахар. Пока в общем, лямбды позволяют коду создавать небольшие функциональные объекты в место, эта поддержка уже была предустановлена ​​- до некоторой степени - в Java язык за счет использования внутренних классов.

Так насколько лучше синтаксис лямбда-выражений? Где он превосходит предыдущие языковые конструкции? Что может быть лучше?

Для начала мне не нравится тот факт, что есть два доступных синтаксиса для лямбда-функций (но это относится к строке C #, поэтому я думаю, что мой мнение не является широко распространенным. Я думаю, если мы хотим приукрасить, то # (int x) (x * x) слаще, чем # (int x) {return x * x; } даже если двойной синтаксис больше ничего не добавляет. Я бы предпочел второй синтаксис, более общий за счет дополнительных затрат на написание return и ; в сокращенных версиях.

Чтобы быть действительно полезными, лямбда-выражения могут принимать переменные из области видимости в где они определены и из замыкания . В соответствии с Внутренние классы, лямбда-выражения ограничены , эффективно захватывая ' final 'переменные. Соответствие предыдущим характеристикам язык - приятная функция, но для сладости было бы неплохо возможность захвата переменных, которые можно переназначить.Для этой цели, они считают, что переменные присутствуют в контексте и аннотированный @Shared будет записан ссылкой , что позволит задания. Мне это кажется странным, поскольку лямбда может использовать переменную определяется в месте объявления переменной, а не где определена лямбда. Одна переменная может использоваться в нескольких чем одна лямбда, и это приводит к одинаковому поведению во всех из них.

Лямбды пытаются имитировать реальные функциональные объекты, но предложение делает не попасть туда полностью: чтобы синтаксический анализатор оставался простым, поскольку до сих пор идентификатор обозначает либо объект, либо метод, который был сохранен согласованный и вызов лямбды требует использования ! после лямбды name: # (int x) (x * x)! (5) вернет 25 . Это приносит новый синтаксис использовать для лямбда-выражений, которые отличаются от остального языка, где ! стоит каким-то образом как синоним для .execute на виртуальном универсальном interface Lambda но почему бы не завершить его?

Можно создать новый общий (виртуальный) интерфейс Lambda . Было бы должны быть виртуальными, поскольку интерфейс - это не настоящий интерфейс, а семейство таких: Lambda , Lambda , Лямбда ...Они могли определить единственное исполнение метод, который я хотел бы быть похожим на C ++ operator () , но если это бремя, тогда подойдет любое другое имя, включающее ! как ярлык для выполнения метода:

 interface Lambda<R> {
    R exec();
 }
 interface Lambda<R,A> {
    R exec( A a );
 }

Тогда компилятору нужно только преобразовать идентификатор! (args) в identifier.exec (args) , это просто. Перевод лямбда-синтаксис потребует от компилятора определения правильного интерфейс реализуется и может быть сопоставлен как:

 #( int x )(x *x)
 // translated to
 new Lambda<int,int>{ int exec( int x ) { return x*x; } }

Это также позволит пользователям определять внутренние классы, которые могут использоваться как лямбды, в более сложных ситуациях. Например, если лямбда функция, необходимая для захвата переменной, аннотированной как @Shared в только для чтения, или поддерживать состояние захваченного объекта в место захвата, ручное выполнение лямбды было бы доступно:

 new Lambda<int,int>{ int value = context_value;
     int exec( int x ) { return x * context_value; }
 };

Аналогично текущему определению внутренних классов, и, таким образом, естественен для нынешних пользователей Java. Это можно было бы использовать, например, в цикле для генерации лямбда-множителей:

 Lambda<int,int> array[10] = new Lambda<int,int>[10]();
 for (int i = 0; i < 10; ++i ) {
    array[i] = new Lambda<int,int>{ final int multiplier = i;
       int exec( int x ) { return x * multiplier; }
    };
 }
 // note this is disallowed in the current proposal, as `i` is
 // not effectively final and as such cannot be 'captured'. Also
 // if `i` was marked @Shared, then all the lambdas would share
 // the same `i` as the loop and thus would produce the same
 // result: multiply by 10 --probably quite unexpectedly.
 //
 // I am aware that this can be rewritten as:
 // for (int ii = 0; ii < 10; ++ii ) { final int i = ii; ...
 //
 // but that is not simplifying the system, just pushing the
 // complexity outside of the lambda.

Это позволит использовать лямбда-выражения и методы, которые принимают лямбда-выражения. с новым простым синтаксисом: # (int x) {return x * x; } или более комплексный ручной подход для конкретных случаев, когда сахарная глазурь вмешивается в предполагаемую семантику.

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