Здравствуйте, VladD2, Вы писали:
VD>Я вот только не понял, что за фигня этот ваш "=>" синтаксис при объявлении членов. Это чтобы блок с return-ом не писать?
Да. Методов это тоже касается.
VD>Если да, то решение спорное. Люди для этого сто лет как используют "=".
Конфликтует с инициализацией.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Это понятно, но тут предлагается это вместо declaration expression.
Вот я и говорю, что одно другому не мешает. Понятно, что крутой вывод типов по использованию МС сейчас не потяент. Но лет за 10 они вполне его могут сделать на должном уровне.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>DE решает только первую проблему, но решает ее лучше туплов, потому что у out параметров есть имена. Ну и собственно DE заменяет операцию распаковки тупла в локальные переменные.
Хреново он ее решает. Неудобно. Лучше бы довели до ума анонимные типы. Сделали бы синтаксисх их декларации по месту, как у записей в ML-е. Например:
AVK>В локальном контексте не так критично. Я только обратил внимание, что неплохо бы добавить вывод типов для локальных констант. Можно заодно расширить их семантику до ro переменных, все равно наружу оно не смотрит и в сборке не фиксируется никак.
А я как сейчас помню восторженную презентацию C# (1.0) в которой рассказывалось о необходимости указывать тип у констант, как о невероятном достоинстве.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>А зачем это нужно в таком виде? Все равно ведь непонятно, что в результате вернется. Лучше уж в специальную структурку завернуть результат.
ЕА>Я бы предпочел, чтобы из анонимных типов можно было результат функции формировать, типа
ЕА>
ЕА>public var F()
ЕА>{
ЕА> return new { Name = "A", Age = 10 };
ЕА>}
ЕА>
А как знать что внутри при вызове метода ?
Уже сейчас можно вернуть object/dynamic и вперед.
Здравствуйте, AndrewVK, Вы писали:
AVK>Говорят, долго. Хорошо хоть прямо не посылают, как раньше.
Это — да. Это большой пробгресс. Глядишь к 8-ке таки урезанный ПМ выкатят, как в Котлине. И на шарпе можно будет программировать без мата вырывания волос на заднице.
AVK>Хотя, казалось бы, при наличии первичного конструктора и определенных ограничениях на внутренности уже никаких discriminated unions добавлять в язык не нужно, связь между параметрами и свойствами и так формально определена. Но, пока, увы.
Тут две проблемы. Одна, как ты верно заметил, связь между полями и параметрами конструктора. Вторая — это описание фиксированных иерархий.
Дело в том, что основной проблемой ПМ по классам является проблема неучтенных расширений (подтипов). Написал ты проверку, а потом добавил еще класс (возможно в другой сборке) и вот у тебя уже потенциальная ошибка в рантайме. Замкнутость алгебраических типов дает контроль над этим делом. Но тут можно sealed использовать. Кривовато, но работать будет.
А вообще, ПМ прекрасно работает и без соответствия параметров и полей. Получается чуть более громоздко, но все же удобнее ифов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Extension properties хочу. Хотя, monadic null checking и constructor type parameter inference тоже ничего. VD>Так давно бы перешол на Немерл. Мы уже много лет всем этим пользуемся.
Я на работе с боями пропихиваю Т4 Фантазёр вы, батенька.
Здравствуйте, VladD2, Вы писали:
VD>Дело в том, что основной проблемой ПМ по классам является проблема неучтенных расширений (подтипов).
Это проблема далеко не только ПМ. Те же визиторы или мультиметоды от нее страдают в полный рост.
VD>Но тут можно sealed использовать. Кривовато, но работать будет.
Тут, скорее, надо просто ввести ключевое слово типа static, которое одновременно и sealed добавит и запретит создание свойств, которые ПМ обработать не сможет.
VD>А вообще, ПМ прекрасно работает и без соответствия параметров и полей.
В этом случае контроля становится существенно меньше.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, VladD2, Вы писали:
AVK>>Ну так если сделать любую конструкцию выражением, то получится то же самое, вид в профиль. VD>Придется сдублировать все конструкции языка.
Да. Впрочем, в случае if начало уже положено .
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, VladD2, Вы писали:
VD>Хреново он ее решает. Неудобно. Лучше бы довели до ума анонимные типы. Сделали бы синтаксисх их декларации по месту
Это было бы, вне всяких сомнений, лучше.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
VD>>Если да, то решение спорное. Люди для этого сто лет как используют "=".
AVK>Конфликтует с инициализацией.
Этот вариант, заметь, еще и тучу вопросов вызывает.
А меж тем все вроде как довольно просто.
Для полей этой проблемы не стоит, так как они только инициализируются.
Для свойств можно использовать синтаксис:
int Prop1 { get; default 42; }
int Prop2 { get x * y; default 42; }
int Prop3 { get { x * y; } default 42; }
int Prop3 { get { return x * y; } default 42; }
А для методов привычный "=":
int Foo() = 42;
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>А зачем это нужно в таком виде? Все равно ведь непонятно, что в результате вернется.
Непонятно это только теоретикам. У практиков проблем с пониманием не возникает.
ЕА>Лучше уж в специальную структурку завернуть результат.
Одно другого не отменяет. Иногда нужно по быстрому кортеж сваять, иногда нужно ясности придать, тут уже записи (описываемые анонимные типы) рулят.
ЕА>Я бы предпочел, чтобы из анонимных типов можно было результат функции формировать, типа
ЕА>
ЕА>public var F()
ЕА>{
ЕА> return new { Name = "A", Age = 10 };
ЕА>}
ЕА>
Это не разумное предложение. Оно быстро сломает интелисенс в больших проектах. В методе может быть 100500 выражений, и методов может быть 100500. Для вывода типов придется протипизировать все их тела. А это самая долгая операция. Решарпер даже не парсит тела методов до того как пользователь к ним не обратится. А ты предлагаешь их все типизировать.
Правильное решение для языка с хорошей поддержкой IDE будет возможность декларировать анонимные типы (превращение их в записи):
public <string Name, int Age> F()
{
return new { Name = "A", Age = 10 };
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Дело в том, что основной проблемой ПМ по классам является проблема неучтенных расширений (подтипов).
AVK>Это проблема далеко не только ПМ. Те же визиторы или мультиметоды от нее страдают в полный рост.
У шаблона Посетитель такой проблемы нет. Там интерфейс определяет список альтернатив. А у мультиметодов вообще проблем хватает. Их и реализовать эффективно сложно, и с защитой проблемы. Но, зато, они расширяемые извне.
AVK>Тут, скорее, надо просто ввести ключевое слово типа static, которое одновременно и sealed добавит и запретит создание свойств, которые ПМ обработать не сможет.
Про статик не понял.
VD>>А вообще, ПМ прекрасно работает и без соответствия параметров и полей.
AVK>В этом случае контроля становится существенно меньше.
Ты не прав. Это не связанные проблемы. Тот же sealed решает проблему закрытости списка альтернатив.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Фантазёр вы, батенька.
