Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, Ziaw, Вы писали:

Z>>Ну да, if в виде выражения уже есть во многих языках. Почему нужно две конструкции вместо одной и нет аналогов для switch, using, try/catch?

ARK>Для if и switch естественны две формы — в виде выражения и статемента. Для остальных я вижу только statement-форму. В принципе, foreach может быть выражением, если у него вместо тела будет предикат типа "all", "any", "max", "min" и т.п. Это грамотный подход. А "выражение, возвращающее ничто" это какая-то хрень. Конструкции using, try в виде выражений все же не представляю.
Можно использовать выражения, которые возвращают какую-то хрень (см F# Unit type) вместо ничто.

Здравствуйте, samius, Вы писали:

S>Можно использовать выражения, которые возвращают какую-то хрень (см F# Unit type) вместо ничто.

Это по сути то же самое.

Если уж делать "все есть выражение", то надо во все функции с побочными эффектами передавать "миры" и возвращать их назад.

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, samius, Вы писали:

S>>Можно использовать выражения, которые возвращают какую-то хрень (см F# Unit type) вместо ничто.

ARK>Это по сути то же самое.
Нет, это лучше, т.к. не требует разделения на функции, возвращающие что-то, и функции,возвращающие void.

ARK>Если уж делать "все есть выражение", то надо во все функции с побочными эффектами передавать "миры" и возвращать их назад.
Как это поможет, если функция с побочным эффектом не принимает мир, а та что принимает — не имеет побочного эффекта, т.к. принимает мир и возвращает новый?

Здравствуйте, samius, Вы писали:

S>Нет, это лучше, т.к. не требует разделения на функции, возвращающие что-то, и функции,возвращающие void.

Я считаю, что разделение должно быть, т.к. по факту оно есть.

S>Как это поможет, если функция с побочным эффектом не принимает мир, а та что принимает — не имеет побочного эффекта, т.к. принимает мир и возвращает новый?

Все верно. С использованием "миров" функций с побочными эффектами не будет и поэтому можно применить подход "все есть выражение".
Имею глубокое убеждение, что в выражении не должно быть побочных эффектов.

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, samius, Вы писали:

S>>Нет, это лучше, т.к. не требует разделения на функции, возвращающие что-то, и функции,возвращающие void.

ARK>Я считаю, что разделение должно быть, т.к. по факту оно есть.
Оно есть, но оно мешает. Заставляет по дважды описывать функции для Func и Action, для Task<T> и Task и т.п.

ARK>Все верно. С использованием "миров" функций с побочными эффектами не будет и поэтому можно применить подход "все есть выражение".
ARK>Имею глубокое убеждение, что в выражении не должно быть побочных эффектов.
Это во власти разработчика. Отобрать такую возможность практически нереально. Но можно подумать о том, что бы помечать особым образом чистые функции/выражения.

Здравствуйте, samius, Вы писали:

S>В принципе такая проблема снимается если можно будет делать так:
S>class MyClass = <A int, B string>;

Это уже совсем иное, чем предлагаемые тут анонимные и структурно эквивалентные типы. Это просто сахар, с ним никаких проблем нет.

S>Но пока описать "настоящий" класс с его конструкторами, Equals/ToString/GetHashCode/==/!= в 10 раз сложнее, чем ввести анонимный.

Ну, видишь, с конструкторами вопрос уже почти решенный.

S>но только если эти предикаты и проекции построены внутри того же метода, где строится линк запрос.

Естественно. И это логично. Во всех остальных ситуациях (ну разве что за исключением нескольких приватных методов одного класса) такой тип становится частью контракта, соответственно выводить его из использования, как в случае анонимных типов это прекрасный способ прострелить себе ногу.

S> Извне передать эти предикаты и проеции нельзя

Можно извне передать проекцию в анонимный тип и предикат для этого анонимного типа.

S>, потому как они используют анонимный тип, который мы не можем указать в сигнатуре.

Указывать его не обязательно, если компилятор сможет вывести.

AVK>>Именно поэтому — узнают.
S>Именно поэтому в ратнайме будут экземпляры лишь одного типа и PropertyGrid-ы не увидят экземпляры совместимых типов.

А в метаданных чего будет?

AVK>>Не будет. Если бы он был обычным, не понадобилось бы менять рантайм.
S>Рантайм меняется лишь для того что бы исключить появление экземпляров других типов.

А как исключить появление разных метаданных для одного типа в разных сборках? Или таки вводим на уровне метаданных новую сущность?

Здравствуйте, VladD2, Вы писали:

VD>Это странный вопрос для человека который видит огромную разницу между Разером и Т4.

Между ними, мягко говоря, разницы побольше, чем между лямбдами и анонимными методами.

VD>Синтаксис. Писать в функциональном стиле с анонимными методами очень некрасиво. Код получается громоздким.

Код получается громоздким прежде всего не из-за анонимных типов, а из-за отсутствия вывода типов.

Здравствуйте, Ziaw, Вы писали:

Z>Я тут с тобой полностью согласен и никаких претензий МС не предъявляю. Тебе показалось.

Мне не показалось, эта реплика для Анонима в основном предназначалась.

Здравствуйте, AlexRK, Вы писали:

ARK>Пардон, а что с аргументом можно внутри сделать, кроме как вызвать ToString?

В данном случае более корректной была бы такая сигнатура:

void CallMethodWithArgument<T>(T[] argument)

А с такой сигнатурой уже кой чего можно сделать — кол-во посчитать, склонировать и т.п.

Здравствуйте, Ziaw, Вы писали:

Z>Я не понимаю, что такое запрет выражений с побочными эффектами. О чем ты сейчас говоришь?

Скорее всего о какой то разновидности state constraints. Вот только в этом случае наличие возможности избежать лишней изменяемой переменной становится еще важнее.

Z>ИМХО надо как-то раскрывать. А то получается, что на все мои аргументы ты возражаешь "мне кажется, что все не так".

Я думаю это, скорее всего, означает "слишком непривычно".

Здравствуйте, AlexRK, Вы писали:

ARK>В принципе, foreach может быть выражением, если у него вместо тела будет предикат типа "all", "any", "max", "min" и т.п. Это грамотный подход.

Вот foreach как раз таки выражением можно и не делать.

ARK> А "выражение, возвращающее ничто" это какая-то хрень. Конструкции using, try в виде выражений все же не представляю.

Вроде уже показали пример. Можно еще проще:

var x = src.Count(i => try { CanThrowException(i) } catch { defaultValue });
var y = src.Sum(i => using(var rc = GetDisposableResource()) rc.Foo(i));

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, Ziaw, Вы писали:

Z>>Ну да, if в виде выражения уже есть во многих языках. Почему нужно две конструкции вместо одной и нет аналогов для switch, using, try/catch?

ARK>Для if и switch естественны две формы — в виде выражения и статемента. Для остальных я вижу только statement-форму. В принципе, foreach может быть выражением, если у него вместо тела будет предикат типа "all", "any", "max", "min" и т.п. Это грамотный подход. А "выражение, возвращающее ничто" это какая-то хрень. Конструкции using, try в виде выражений все же не представляю.

Это потому что не та траву язык

using, try и т.д. не обязаны возвращать void, а могут вернуть последнее выражение.
Точно также как и функция, последнее выражение является и значением функции.

Скажем вот так

 def x = using(a = A()) { 1 };

Вот применение try-catch

Автор: VladD2
Дата: 18.04.11

.

Z>>Я не понимаю, что такое запрет выражений с побочными эффектами. О чем ты сейчас говоришь?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, samius, Вы писали:

S>>class MyClass = <A int, B string>;

AVK>Это уже совсем иное, чем предлагаемые тут анонимные и структурно эквивалентные типы. Это просто сахар, с ним никаких проблем нет.
Согласен. А можем мы в пределах хотя бы сборки считать MyClass и <A int, B string> синонимами? А в сборках, ссылающихся на сборку, где объявлен MyClass, при наличии соответствующей using директивы?

S>>Но пока описать "настоящий" класс с его конструкторами, Equals/ToString/GetHashCode/==/!= в 10 раз сложнее, чем ввести анонимный.

AVK>Ну, видишь, с конструкторами вопрос уже почти решенный.
Все остальное от анонимного типа вполне бы устроило. В том числе риадонли свойства.

S>>но только если эти предикаты и проекции построены внутри того же метода, где строится линк запрос.

AVK>Естественно. И это логично. Во всех остальных ситуациях (ну разве что за исключением нескольких приватных методов одного класса) такой тип становится частью контракта, соответственно выводить его из использования, как в случае анонимных типов это прекрасный способ прострелить себе ногу.
Верно. Если будет короткий способ объявить такой тип, то это поможет. Кстати, в F# тип record коротко объявляется и при создании экземпляра указывать имя не нужно, компилятор выводит тип сам.

S>> Извне передать эти предикаты и проеции нельзя

AVK>Можно извне передать проекцию в анонимный тип и предикат для этого анонимного типа.
Это интересно. Linq2Sql скушает запрос с такой проекцией?
Беда тут в том, что как только мы в запросе воспользуемся этой проекцией, мы получим тип T, чьи свойства мы не знаем. Разобрать его уже не выйдет, если мы не передадим проекции T->XYZ для каждого свойства тоже извне.

S>>, потому как они используют анонимный тип, который мы не можем указать в сигнатуре.

AVK>Указывать его не обязательно, если компилятор сможет вывести.
Если передать вместе с проекцией, то сможет.

AVK>>>Именно поэтому — узнают.
S>>Именно поэтому в ратнайме будут экземпляры лишь одного типа и PropertyGrid-ы не увидят экземпляры совместимых типов.

AVK>А в метаданных чего будет?
В метаданных не будет ничего такого, чего нет у анонимного типа. Конечно, если мы не разрешим вешать атрибуты при объявлении
class MyClass = <[MyAttribute]A:int, ...>

AVK>>>Не будет. Если бы он был обычным, не понадобилось бы менять рантайм.
S>>Рантайм меняется лишь для того что бы исключить появление экземпляров других типов.

AVK>А как исключить появление разных метаданных для одного типа в разных сборках? Или таки вводим на уровне метаданных новую сущность?
Вот, если честно, то к подмене типов в рантайме я немного охладел. И к маппингу тоже.

Теперь мысль крутится следующая: сделать рекорды как в F#, но генерацию типа сделать в точности как сейчас у анонимных типов. Отличие лишь в том, что у него будет цивилизованное имя.
Если при использовании анонимного типа в видимости оказывается запись с соответствующими свойствами, то компилятор вместо анонимного типа использует тип записи. Иначе — генерит анонимный тип.
Использованием считать
а) то как объявляются анонимные типы сейчас, т.е. new { A = 5, B = "10" }
б) объявления вроде <A:int, B: string> (в прямой видимости объявления class MyClass = <A:int, B: string> считать их синонимами).

Здравствуйте, AlexRK, Вы писали:

ARK>Для if и switch естественны две формы — в виде выражения и статемента. Для остальных я вижу только statement-форму.

И снова "мне кажется, что все не так". Обоснуй. Выражение от стейтмента сейчас отличается тем, что statement возвращает void, а большинство statements должно возвращать результат последнего выражения.

ARK>В принципе, foreach может быть выражением, если у него вместо тела будет предикат типа "all", "any", "max", "min" и т.п. Это грамотный подход.

Как раз этот подход вполне заменяется экстеншен методами для IEnumarable. foreach должен возвращать void (либо быть аналогом Select, но это не очень хороший вариант).

ARK>А "выражение, возвращающее ничто" это какая-то хрень.

Просто ты не хочешь это принимать. Потому команда C# и делает лишь маленький шажок. Вот ты попользуешься и начнешь сам хотеть побольше выражений.

ARK>Конструкции using, try в виде выражений все же не представляю.

Чего их представлять-то, уже привели все примеры.

ARK>Это я гипотетически говорю. Что хорошо бы функции с побочными эффектами запрещать использовать в выражениях вообще. Только в виде стейтментов. Понятно, что это не о C#.

Тут очень сложный вопрос, например db.Table1.Count() это функция с побочными эффектами?

ARK>Про легкость обнаружения ошибок я аргументов не увидел.

Код читабельнее. Алгоритм понимается быстрее. Иммутабельные переменные не позволяют пропустить место, где переменная "незаметно" меняется.

ARK>Может это и не проблема вовсе? Раз уж речь идет о гипотетическом расширении языка, то можно дать возможность объявлять переменные как "var" без инициализации (кстати, непонятно, почему этого не сделали).

Можно конечно, только зачем? Мы решим эту локальную проблему ценой снижения читабельности кода.

Здравствуйте, samius, Вы писали:

S>В принципе такая проблема снимается если можно будет делать так:
S>class MyClass = <A int, B string>;

Так это и сделали. Праймари конструктор же.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, samius, Вы писали:

S>>В принципе такая проблема снимается если можно будет делать так:
S>>class MyClass = <A int, B string>;

Z>Так это и сделали. Праймари конструктор же.
Само по себе это хорошо, но будет ли это совместимо с анонимными типами?

Здравствуйте, samius, Вы писали:

S>Согласен. А можем мы в пределах хотя бы сборки считать MyClass и <A int, B string> синонимами? А в сборках, ссылающихся на сборку, где объявлен MyClass, при наличии соответствующей using директивы?

Слишком кучеряво, имхо.

AVK>>Можно извне передать проекцию в анонимный тип и предикат для этого анонимного типа.
S>Это интересно. Linq2Sql скушает запрос с такой проекцией?

Это основной сценарий применения анонимных типов в линке.

S>Беда тут в том, что как только мы в запросе воспользуемся этой проекцией, мы получим тип T, чьи свойства мы не знаем.

Опять я перестаю тебя понимать. Там где мы анонимный тип конструируем, в том методе все его свойства мы знаем. А в других методах работать с типом, который выводится из использования в чужом коде — довольно странная идея.

AVK>>А в метаданных чего будет?
S>В метаданных не будет ничего такого, чего нет у анонимного типа.

Так анонимные типы в разных сборках разные, поэтому там такой проблемы не стоит.

S> Конечно, если мы не разрешим вешать атрибуты при объявлении
S>class MyClass = <[MyAttribute]A:int, ...>

При чем тут атрибуты? Ты вытаскиваешь свой хитрый тип в контракты, значит он должен присутствовать в метаданных. Если ничего не делать, то одинаковые в рантайме типы в метаданных будут разными.

Здравствуйте, Ziaw, Вы писали:

Z>Так это и сделали. Праймари конструктор же.

Свойства все равно ручками надо декларировать, хоть и по упрощенной схеме.

Здравствуйте, samius, Вы писали:

S>Само по себе это хорошо, но будет ли это совместимо с анонимными типами?

В каком смысле совместимо? Если ты нормальный тип задекларировал анонимныей уже не нужен.

Здравствуйте, AndrewVK, Вы писали:

AVK>Между ними, мягко говоря, разницы побольше, чем между лямбдами и анонимными методами.

Э... я даже затрудняюсь квалифицировать данное утверждение. Его кроме как для флэйму и сказать то нельзя.

delegate(Dictionry<int, string> d, int value) { return d[value]; }

sv.

(d, value) => d[value]

мало различимы? Ты это серьезно?

VD>>Синтаксис. Писать в функциональном стиле с анонимными методами очень некрасиво. Код получается громоздким.

AVK>Код получается громоздким прежде всего не из-за анонимных типов, а из-за отсутствия вывода типов.

Дык он часть синтаксических расширений введенных для реализации лямбд.

В прочем, все эти delegate и return сами по себе убивают читабельность чуть менее чем полностью.