Почему не делегаты стиля.NET, а не закрытия в Java?
Хорошо, это будет моим избиением умирающей лошади в 3-й раз.
Однако этот вопрос отличается от моих более ранних двух о закрытиях/делегатах, который спрашивает о планах относительно делегатов и что является спроектированными спецификациями и реализацией для закрытий.
Этот вопрос о - почему сообщество Java изо всех сил пытается определить 3 различных типов закрытий, когда мы могли просто украсть целое понятие блокировки делегатов, запаса и барреля от нашего любимого и дружелюбного соседа - Microsoft.
Существует два нетехнических заключения, в которые я очень испытал бы желание вскочить:
- Сообщество Java должно поддержать свою гордость, за счет необходимости пойти thro замысловатые усилия, не уступив заимствованию никаких понятий Microsoft или иначе доказать блеск Microsoft.
- Делегаты являются запатентованной технологией Microsoft.
Хорошо, помимо вышеупомянутых двух возможностей,
Q1. Есть ли слабость или несоответствие в делегатах стиля.NET, к которым обратились бы три (или больше) формы закрытий?
Q2. Я спрашиваю это при смещении между Java и C#, и он заинтриговывает меня, что делегаты C# делают точно, в чем я нуждался. Есть ли опции, которые были бы реализованы в закрытиях, которые не в настоящее время доступны в делегатах C#? Раз так, каковы они, потому что я не вижу то, что мне нужны больше, чем, каких делегатов C# соответственно предоставил мне?
Q3. Я знаю, что одни из опасений по поводу реализации закрытий/делегатов в Java являются сокращением ортогональности языка, где больше чем один путь выставляется для выполнения конкретной задачи. Действительно ли это стоит свертки уровня и время, проведенное для ухода от делегатов только, чтобы гарантировать, что Java сохраняет свой уровень ортогональности? В реляционном дизайне мы знаем, что желательно повредить ортогональность путем часто соответственно удовлетворения только 2-й нормальной формы. Почему Java не может быть подвергнут сокращению ортогональности и мыса OO ради простоты?
Q4. Архитектура JVM технически ограничивается от реализации разработанных.NET делегатов. Если эта причина БЫЛА (сослагательное наклонение для подчеркивания неправдоподобности) верный, то, почему не может, эти три предложения по закрытиям скрыты позади простого ключевого слова делегата или аннотации: если нам не нравится использовать @delegate, мы могли бы использовать @method. Я не вижу, как формат оператора делегата более сложен, чем три предложения по закрытию.
2 ответа
В C # есть закрытие в дополнение к делегатам. На мой взгляд, это не одно и то же.
делегат = указатель на функцию.
closure = {функция, среда}. Способ определения [анонимной] функции и упаковки ее в ее окружение. Строго говоря, последнее следует называть только закрытием, а первое - «лямбда-выражением».
Ваш вопрос ироничен. Вам интересно, почему сообщество Java борется с тремя различными предложениями по добавлению замыканий, а предлагаемое вами решение - добавить четвертый вариант?
Но чтобы ответить на ваш вопрос:
Правильным форумом для обсуждения является список рассылки openjdk project lambda. Это не то место, где предложения могут повлиять на эти усилия.
Системы типов для C# и Java существенно отличаются, поэтому решение для C# не будет применимо напрямую. Например, в C# есть дисперсия места объявления (in/out), а в java - дисперсия места использования (wildcards). Вывод типов параметров лямбда-функций, определенный в C#, не будет применяться в Java.
Эволюция Java должна оставаться обратно совместимой, но добавление ключевого слова delegate было бы разрушающим изменением.
В C# есть три типа выражений делегата: старый вариант с ключевым словом delegate, лямбды оператора с =>{ и лямбды выражения. Если бы команде разработчиков языка C# пришлось делать все заново, у нас бы точно не было такого количества форм. Почему Java должна перенимать исторический багаж C#?
Поскольку дженерики в C# работают над примитивами, типы делегатов Func<> и Action<> можно использовать как структурные типы функций. Но в Java дженерики стерты, работают только над ссылочными типами, и типы нельзя различать по их четности. Следовательно, для достижения того же эффекта в Java пришлось бы иметь большое количество "стандартных" типов функций с разными именами. Это было бы некрасиво.
В целом, решение C# не адаптируется к очень естественному решению в Java.