Нравится ли вам синтаксис Linq? В минималистичном виде:
from e in list where e % 2 select e
Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.
Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нравится ли вам синтаксис Linq?
Предпочитаю манипулировать стандартными ФВП, хотя в C# это получается тяжеловесней, чем в F#/Haskell (зато единообразно). Query comprehesion syntax делали в угоду программистам, знакомым с SQL. Я же SQL как не знал, так и не знаю :) Так что мне такой синтаксический сахар не сладок.
Здравствуйте, Qbit86, Вы писали:
Q>Предпочитаю манипулировать стандартными ФВП, хотя в C# это получается тяжеловесней, чем в F#/Haskell (зато единообразно). Query comprehesion syntax делали в угоду программистам, знакомым с SQL. Я же SQL как не знал, так и не знаю Так что мне такой синтаксический сахар не сладок.
Linq — это скорее генератор, он все же ленивый. Но суть не в этом.
Ну а что бы хотели видеть вместо Linq-a? Синтаксис я имею в виду. С учетом того, что C# язык весьма Си-подобный и классическая Set Builder нотация могла бы "сорвать крышу" многим пользователям.
Плюс Linq таки "круче" стандартных генераторов — есть и orderby, group by и let. Я, например, с трудом представляю, как все это впихнуть в хаскелевский list comprehension, чтобы не получилась каша.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>...и классическая Set Builder нотация могла бы "сорвать крышу" многим пользователям... Я, например, с трудом представляю, как все это впихнуть в хаскелевский list comprehension, чтобы не получилась каша.
Я не про set buider и не про list comprehension, я про стандартные ФВП вроде map—filter—fold/reduce (и их C#-аналоги Select—Where—Aggregate).
ВВ>Плюс Linq таки "круче" стандартных генераторов — есть и orderby, group by и let.
Всё, что можно выразить в терминах query comprehension syntax, можно выразить и в терминах ФВП (хоть и не всегда лаконично). Так, например, есть extension-методы OrderBy/ThenBy и GroupBy, let же воспроизводится введением промежуточного кортежа (в C# удобно использовать синтаксис анонимных классов). Кроме того, есть много других полезных ФВП, которые через query comprehension syntax не выражаются. Приходится «смешивать языки» — часть запроса писать на SQL-подобном языке, затем оборачивать в скобки и добавлять вызов C# extension-методов — получается немного эклектичненько.
ВВ>Linq — это скорее генератор, он все же ленивый.
Лень никуда не девается. Linq ничего нового в рамках CLR или ядра языка не предоставляет, всё в результате компилируется в обычные сатические функции, возвращающие санки.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:
ВВ>
ВВ>from e in list where e % 2 select e
ВВ>
ВВ>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот. ВВ>Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом.
Неправильный синтаксис, нелогичный.
Чем плох стандартный:
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нравится ли вам синтаксис Linq?
"Ненавижу и стремлюсь уничтожить" (с)
Linq применяю только в синтаксисе extention-методов c лямбдами.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:
ВВ>
ВВ>from e in list where e % 2 select e
ВВ>
ВВ>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.
В нем есть ровно два лишних элемента from и select. По уму он не должен отличаться от вызова соответствующих функций:
where e % 2
ВВ>Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом.
А интелисенс тут вообще никаким боком не влияет ни на что. Это чистые заморочки тех кто придумывал синтаксис. Обязательное наличие from уменьшает количество ключевых слов которое нужно контролировать в обычных выражениях для того чтобы выявить линк-выражение, а обязательное наличие select позволяет упростить выявление окончания линк-выражения. Можно было пойти другим путем — ввести специальное ключевое слово или символ предваряющее запрос или заставить брать запрос в скобки при неоднозначностьях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:
ВВ>
ВВ>from e in list where e % 2 select e
ВВ>
Нравится все, гораздо лучше синтаксиса SQL-я.
Не хватает: возможности использовать номер строки (доступно через extension-метод) + хотелось бы в join использовать произвольне условие, а не только равенство (эмулируется через доп. from + where, но выглядит корявее).
Здравствуйте, VladD2, Вы писали:
ВВ>>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот. VD>В нем есть ровно два лишних элемента from и select. По уму он не должен отличаться от вызова соответствующих функций: VD>
VD>where e % 2
VD>
А как писать выражение для выборки? Ну т.е. select — это же просто (забыл умное слово) средство для трансформации списка.
Кстати, в Немерле, я так вижу, синтаксис воспроизведен один в один. Или это сделано из политических соображений?
ВВ>>Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом. VD>А интелисенс тут вообще никаким боком не влияет ни на что. Это чистые заморочки тех кто придумывал синтаксис. Обязательное наличие from уменьшает количество ключевых слов которое нужно контролировать в обычных выражениях для того чтобы выявить линк-выражение, а обязательное наличие select позволяет упростить выявление окончания линк-выражения. Можно было пойти другим путем — ввести специальное ключевое слово или символ предваряющее запрос или заставить брать запрос в скобки при неоднозначностьях.
Ну мне казалось, это одна из причин, почему from идет перед select — ведь в противном случае мы не знаем тип выражения, которое пишется в select, и интелли-сенс работать не будет.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А как писать выражение для выборки? Ну т.е. select — это же просто (забыл умное слово) средство для трансформации списка.
Слово называется — отображение. Ну, так если оно нужно, то его нужно и использовать. Просто глупо что-то использовать только из соображений синтаксических предпочтений создателей языка.
ВВ>Кстати, в Немерле, я так вижу, синтаксис воспроизведен один в один. Или это сделано из политических соображений?
Селект можно опускать.
ВВ>Ну мне казалось, это одна из причин, почему from идет перед select — ведь в противном случае мы не знаем тип выражения, которое пишется в select, и интелли-сенс работать не будет.
Причина этого синтаксиса одна — предпочтения его разработчика.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Кстати, в Немерле, я так вижу, синтаксис воспроизведен один в один. Или это сделано из политических соображений? VD>Селект можно опускать.
Так претензия только в том, что в Линке селект нельзя опускать?
ВВ>>Ну мне казалось, это одна из причин, почему from идет перед select — ведь в противном случае мы не знаем тип выражения, которое пишется в select, и интелли-сенс работать не будет. VD>Причина этого синтаксиса одна — предпочтения его разработчика.
Ну а какой бы ты выбрал синтаксис, если бы не было необходимости поддерживать совместимость с Линком?
Здравствуйте, Lloyd, Вы писали:
L>А что должен вернуть такой запрос: L>
L>from a in aaa
L>from b in bbb
L>
Ну кстати да, даже в насквозь математической Set Builder нотации есть специальный обязательный clause, с которого начинается все выражение и который как раз полностью дублирует select по своему смыслу.
А вот "from a" это халтура, так как служит исключительно для ввода переменной, тогда как для этой же цели можно было использовать и select.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну а какой бы ты выбрал синтаксис, если бы не было необходимости поддерживать совместимость с Линком?
Я бы его вообще не вводил, если честно.
Для работы с СУБД я бы создал специализированный язык базирующийся на SQL-03 (или какой там текущий стандарт?) и встроил бы его в язык. А ЛИНК оставил бы в виде библиотеки.
Единственное где удобен синтаксис — это в join. Но join чаще встречается при работе с БД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.