Здравствуйте, nikov, Вы писали:
VD>>Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.
N>Вы учтите, что в C# некоторые вещи запатентованы, так что имеет смысл заранее поговорить с юристом.
Если серьезно, то только рухнув с дубу можно начать судиться по такому поводу, да еще и не ясно с кем, так как в отличии от Новела, мы даже фирмой не являемся и коммерцией не занимаемся.
В прочем, я вообще не понимаю, что там можно было патентовать? Шарп содран с Явы. Это ясно как божий день. Ни одной новой фичи в нем нет. Что в нем патентовать то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>А ты уверен, что у Novell и Microsoft нет никакого соглашения о кросс-лицензировании? Они как-никак партнеры.
Я уверен в том, что день когда МС засудит кого-то по патентам на дотнет будет предпоследним днем в который у кого-то возникнет идея создавать какие-то продукты на базе стандартов МС.
А отношения между Новелом и МС меня не трогают, как не трогает партнерство между львом и антилопой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_>И что изменилось? Как программист в случае индексации [] я получаю подсказку что имеет место обращение к коллекции, которая как-то индексируется. Что при повторном обращении с тем же набором индексов [a, b] — я получу тот же самый элемент что и в прошлый раз (в случае ссылочных типов — так и reference equal элемент), что я могу по этой коллекции прокатить foreach или select, и т.п. Повторюсь — индексаторы это костыль к методам, но не больший костыль чем свойства. Да и есть уже один язык который подвергся тотальной унификации и теперь сидит в очень узкой нише — lisp. Лиспу никаких скобок кроме круглых не надо, но и писать на нём готовы считанные люди.
ИМХО, наиболее приятной альтернативой представляется индексатор с круглыми скобками.
1) Он не вводит никаких новых символов в конструкции, а только убирает (точку).
2) Он есть в VB.NET
3) Индексатор в .NET — это метафора "свойство с параметрами", или же "дефолтное свойство с параметрами" в случае this[]. Как отметили выше, в С индексатор — это метафора прямого доступа к памяти, которая в безопасном дотнете не совсем уместна. То, что такой синтаксис оставили (в С#) для массивов, а также дали возможность объявлять свои индексаторы — это, имхо, для блюдения все того же принципа "наименьшей болезенности" при переходе с С/С++. То есть в С — это доступ к памяти, в С++ -доступ к памяти/вызов перегруженного оператора [], в С# — это таки вызов метода, и круглые скобки для него, имхо, были бы логичнее даже в C#.
4) При всем уважении к доводам процитированного автора — "обращение к коллекции", "тот же самый элемент", "могу прокатить foreach" — это не всегда, мягко говоря, верно, и относиться больше к code conventions и рекомендациям по дизайну классов.
5) (Могу ошибаться) Так ли уж часто в прикладном коде на функциональном языке нужен индексатор? В Dictionary словаря можно Item(TKey key) использовать.
Здравствуйте, sto, Вы писали:
sto>5) (Могу ошибаться) Так ли уж часто в прикладном коде на функциональном языке нужен индексатор? В Dictionary словаря можно Item(TKey key) использовать.
Мои написанные на Немерле алгоритмы часто работают с гигабайтами данных. Без массивов тут — никуда.
Здравствуйте, VladD2, Вы писали:
VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями. VD>Приветствуются любые мысли!
Функциональный язык к новым синтаксисом уже есть, имхо F# прочно займет эту нишу, да и "железные" языки подтягиваются. Поэтому для Немерле было бы лучше остаться си-шарпом-на-стероидах, а значит иметь максимальную совместимость с его синтаксисом.
Здравствуйте, seregaa, Вы писали:
S>Функциональный язык к новым синтаксисом уже есть,
С новым, говоришь?
Этому новому синтаксису где-то около 30 лет.
S>имхо F# прочно займет эту нишу, да и "железные" языки подтягиваются. Поэтому для Немерле было бы лучше остаться си-шарпом-на-стероидах, а значит иметь максимальную совместимость с его синтаксисом.
Согласен. Но дизайн языка — это всегда компромиссы. В данном случае имеет место компромисс между похожестью на шарп и однозначностью синтаксиса. На мой взгляд большая однозначность лучше, так как она способствует как упрощению языка, так и лучшей его расширяемости. А расширяемость — конек Немерле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, seregaa, Вы писали:
S>>Функциональный язык к новым синтаксисом уже есть, VD>С новым, говоришь? VD>Этому новому синтаксису где-то около 30 лет.
Я имел ввиду новизну не в историческом смысле, а в смысле незнакомости для c# программистов, who new to functional programming.
VD>Согласен. Но дизайн языка — это всегда компромиссы. В данном случае имеет место компромисс между похожестью на шарп и однозначностью синтаксиса. На мой взгляд большая однозначность лучше, так как она способствует как упрощению языка, так и лучшей его расширяемости. А расширяемость — конек Немерле.
Чтобы как следует расчуствовать расширяемость, разработчик должен сначала попробовать язык в деле. А для этого "первая доза должна быть бесплатной", и каждое отличие в синтаксисе имхо увеличивает эту плату.
Я не за идентичности синтаксиса любой ценой, но за максимально возможное соответствие. Мой пост можно расценивать как вклад в копилку аргументов за сохранение угловых скобок, пусть и с двоеточием в виде префикса. А окончательное решение конечно нужно принимать по совокупности всех аргуменов.
Здравствуйте, seregaa, Вы писали:
S>Чтобы как следует расчуствовать расширяемость, разработчик должен сначала попробовать язык в деле. А для этого "первая доза должна быть бесплатной", и каждое отличие в синтаксисе имхо увеличивает эту плату.
S>Я не за идентичности синтаксиса любой ценой, но за максимально возможное соответствие. Мой пост можно расценивать как вклад в копилку аргументов за сохранение угловых скобок, пусть и с двоеточием в виде префикса. А окончательное решение конечно нужно принимать по совокупности всех аргуменов.
И получается, что интересы новичков начинают конфликтовать с интересами тех, кто использует язык по полной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Собственно сделать это не сложно. Но есть три вопроса: VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями. VD>2. Нужно ли делать это до выпуска версии 1.0 или отложить смену синтаксиса до будущей версии? VD>3. Делать ли такую смену в виде ключа компиляции допускающего как квадратные скобки с точкой (как принято сейчас), так и новые скобки?
VD>Приветствуются любые мысли!
А может оставить < > но ввести слово typename как было в шаблонах с++ ?
То сть тогда @ преобеает смылсл слова "специализируется". Dictionary специализируеься type1 и Type 2
Возможность укзать явно, для каких аргументов генерика какой тип принять — мне нравится.
Этого варианта в голсовании нет.
Здравствуйте, hardcase, Вы писали:
H>А может заюзать подчеркивание? Оно глаза не так мозолит, как разные, в сущности мусорные, символы?
H>Dictionary_[Type1, type2]
Не выйдет, к сожалению
_ вполне легальный символ в любом литерале, причём на любой позиции. ИМХО, такой вариант создаст ещё больше неоднозначностей, чем <> или [].