Причини видалення типів функцій на Java 8

Я намагаюся зрозуміти, чому експертна група JDK 8 Lambda (EG) вирішила не включати новий тип функції в мову програмування Java.

Переходячи над списком розсилки, я знайшов нитку з дискусією про видалення типів функцій .

Багато тверджень для мене неоднозначні, можливо, через відсутність контексту, а в деяких випадках через мої обмежені знання щодо впровадження типних систем.

Однак є кілька питань, які, на мою думку, я можу сміливо сформулювати на цьому веб-сайті, щоб допомогти мені зрозуміти, що вони мали на увазі.

_{Я знаю, що міг би задати питання у списку розсилки, але нитка стара і всі рішення вже прийняті, тому є ймовірність, що мене проігнорують, перш за все бачачи, що ці хлопці вже затримуються зі своїми планами.}

У своїй відповіді на підтримку видалення типів функцій та схвалення використання типів SAM Брайан Гец говорить:

Немає вдосконалень. Існував довгий потік про те, наскільки корисним було б переформатування типів функцій. Без внесення змін, типи функцій сплющуються.

Я не зміг знайти нитку, яку він згадує. Тепер я можу зрозуміти, що впровадження структурного типу функцій може спричинити певні ускладнення в системі Java здебільшого номінального типу, що я не можу зрозуміти, наскільки параметризовані типи SAM відрізняються за зміною.

Чи не є вони обома проблемами вдосконалення? Хтось розуміє, наскільки типи функцій відрізняються від параметризованих типів SAM з точки зору переробки?

В іншому коментарі Гец говорить:

Існує два основних підходи до введення тексту: номінальний та структурний. Ідентифікація номіналу заснована на його назві; ідентичність структурного типу заснована на тому, з чого він складається (наприклад, "кортеж int, int" або "функція від int до float".) Більшість мов вибирають переважно номінальну або переважно структурну; Є не так багато мов, які успішно поєднують номінальну та структурну введення, за винятком "навколо країв". Java майже цілком номінальна (за кількома винятками: масиви є структурним типом, але внизу завжди є номінальний тип елементів; у загальних рисах також є суміш іменних і структурних, і це фактично є частиною джерела багатьох скарг людей на дженерики.) Перенесення системи структурних типів (типів функцій) на Java ' Система номінального типу означає нові складності та крайні корпуси. Чи варто того виду функцій?

Ті з вас, які мають досвід впровадження систем типу. Чи знаєте ви якісь приклади цих складностей чи крайових випадків, про які він згадує тут?

Чесно кажучи, я плутаюсь у цих твердженнях, коли вважаю, що мова програмування на зразок Scala, яка повністю базується на JVM, має підтримку структурних типів, таких як функції та кортежі, навіть із проблемами переробки основної платформи.

Не зрозумійте мене неправильно, я не кажу, що тип функції повинен бути кращим, ніж типи SAM. Я просто хочу зрозуміти, чому вони прийняли таке рішення.

Підхід SAM насправді дещо схожий на те, що Scala (і C ++ 11) роблять з анонімними функціями (створеними за допомогою =>оператора Scala або []()синтаксису C ++ 11's (лямбда)).

Перше питання, на яке потрібно відповісти на стороні Java, - чи мати тип повернення оператора lambda бути новим типом primitve, як intабо byte, або тип об'єкта якогось типу. В Scala, там немає жодного примітивного типу - навіть ціле число є об'єктом класу Int- і функція не відрізняється, що є об'єктами класу Function1, Function2і так далі, в залежності від кількості аргументів функції приймає.

C ++ 11, рубін і пітон так само мають лямбда-вирази, які повертають об'єкт, який можна викликати явно або неявно. Повертається об'єкт має деякий стандартний метод (наприклад, #callякий можна використовувати для виклику його як функції. Наприклад, C ++ 11 використовує std::functionтип, який перевантажує operator()так, що виклики методу виклику об'єкта навіть виглядають як текстові виклики, текстуально. :-)

Там, де нова пропозиція для Java стає безладною, полягає у використанні структурного набору тексту, щоб дозволити призначити такий метод іншому об'єкту, наприклад, у Comparatorякого є єдиний основний метод з іншою назвою . Хоча це концептуально непривабливе в деякому сенсі, це робить означає , що отриманий об'єкт може бути переданий в існуючі функції , які приймають об'єкт для подання на зворотний дзвінок, компаратора, і так далі, і очікувати , щоб бути в змозі назвати цілком певний сингл такий спосіб, як #compareабо #callback. Трюк C ++ operator()акуратно ухилився від цього питання ще до C ++ 11, оскільки всі такі варіанти зворотного виклику можна дзвонити однаково, і, таким чином, STL не потребував коригування, щоб дозволити використовувати C ++ 11 лямбда зsortі так далі. Java, що раніше не використовувала стандартні імена для таких об'єктів (можливо, тому, що жоден фокус, як перевантаження оператора, не зробив очевидним єдиний підхід), не так пощастило, тому цей хакер заважає їм змінювати цілу партію існуючих API .