То есть мы помещаем функцию внутрь объекта, чтобы иметь возможность передавать ее как значение. Таким образом, объекты первого класса долгое время были альтернативным решением.
JDK 8 просто упрощает реализацию этой концепции, и они называют этот тип интерфейсов-оболочек «функциональными интерфейсами» и предлагают некоторый синтаксический сахар для реализации объектов-оболочек.
Но в конечном итоге мы по-прежнему используем первоклассные объекты. И они имеют свойства, аналогичные функциям первого класса. Они инкапсулируют поведение, их можно передавать как аргументы и возвращать как значения.
В соответствии с тем, что мы обсуждали сегодня, вот быстрый взгляд на то, куда мы движемся. Мы исследовали путь «возможно, лямбда-выражения должны быть просто экземплярами внутреннего класса, это было бы очень просто», но в итоге пришли к позиции «функции — лучшее направление для будущего языка».
Это исследование проходило поэтапно: сначала внутри группы до формирования ЭГ, а затем еще раз, когда ЭГ обсуждала проблемы. Ниже представлена моя позиция по этому вопросу. Надеюсь, это заполнит некоторые пробелы между тем, что сейчас говорится в спецификации, и тем, что мы говорим об этом.
Возникшие вопросы о том, являются ли лямбда-выражения объектами или нет, в значительной степени сводятся к философским вопросам, таким как «что такое лямбда-выражения на самом деле», «почему Java выиграет от лямбда-выражений» и, в конечном счете, «как лучше развивать язык и платформу Java».
Позиция Oracle заключается в том, что Java должна развиваться — разумеется, осторожно — чтобы оставаться конкурентоспособной. Это, конечно, сложная балансировка.
Я считаю, что лучшим направлением развития Java является поощрение более функционального стиля программирования. Роль Lambda в первую очередь заключается в поддержке разработки и использования более функциональных библиотек; Я предложил такие примеры, как filter-map-reduce, чтобы проиллюстрировать это направление.
В экосистеме имеется множество свидетельств, подтверждающих гипотезу о том, что при наличии инструментов, позволяющих легко это сделать, объектно-ориентированные программисты готовы использовать функциональные методы (такие как неизменность) и превращать их в объектно-ориентированное представление о мире. , и в результате будет писать более качественный, менее подверженный ошибкам код. Проще говоря, мы считаем, что лучшее, что мы можем сделать для Java-разработчиков, — это мягко подтолкнуть их к более функциональному стилю программирования. Мы не собираемся превращать Java в Haskell или даже в Scala. Но направление понятно.
Lambda — это первый взнос за эту эволюцию, но это далеко не конец истории. Остальная часть истории еще не написана, но сохранение наших вариантов является ключевым аспектом того, как мы оцениваем решения, которые принимаем здесь.
Вот почему я так упорно настаивал на том, что лямбда-выражения не являются объектами. Я считаю, что позиция «лямбды — это просто объекты», хотя и очень удобная и заманчивая, захлопывает дверь в ряде потенциально полезных направлений эволюции языка.
В качестве одного примера возьмем типы функций. Лямбда-соломинка, предлагаемая на devoxx, имела типы функций. Я настоял, чтобы мы их удалили, и это сделало меня непопулярным. Но мое возражение против функциональных типов заключалось не в том, что я не люблю функциональные типы — я люблю функциональные типы, — а в том, что функциональные типы плохо боролись с существующим аспектом системы типов Java — стиранием. Типы стертых функций — худшее из обоих миров. Поэтому мы убрали это из дизайна.
Но я не хочу говорить, что «в Java никогда не будет типов функций» (хотя я понимаю, что в Java может никогда не быть типов функций). Я считаю, что для того, чтобы добраться до типов функций, мы должны сначала иметь дело со стиранием. Это может быть, а может быть и невозможно. Но в мире материализованных структурных типов функциональные типы приобретают гораздо больший смысл.
Мировоззрение лямбда-объектов противоречит этому возможному будущему. Взгляд на мир как лямбда-функция не работает, и сохранение этой гибкости является одним из аргументов в пользу того, чтобы не обременять лямбда-выражения даже видимостью объектности.
Вы можете подумать, что текущий дизайн тесно связан с блоком объектов для лямбда-выражений — типов SAM — что делает их в любом случае эффективными объектами. Но это было тщательно скрыто от поверхности, чтобы мы могли в будущем рассмотреть «голые» лямбда-выражения, или рассмотреть другие контексты преобразования для лямбда-выражений, или более тесно интегрировать лямбда-выражения в управляющие конструкции. Мы не делаем этого сейчас, и у нас даже нет конкретного плана для этого, но возможность сделать это в будущем является важной частью дизайна.
Я с оптимизмом смотрю в будущее Java, но чтобы двигаться вперед, нам иногда приходится отказываться от некоторых удобных идей. Лямбда-функции открывают двери. Lambdas-are-objects закрывает их. Мы предпочитаем, чтобы эти двери оставались открытыми.
