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

VD>Я вот только не понял, что за фигня этот ваш "=>" синтаксис при объявлении членов. Это чтобы блок с return-ом не писать?
VD>Если да, то решение спорное. Люди для этого сто лет как используют "=".

Да, C# это не Немерле и никогда, слава богу, им не будет.

В С# с первой версии = для присваивания. => уже используется для лямбд, что бы блок с ретурном не писать. Так что всё очевидно

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

A>Ты предалагешь SQL генерировать с помошью Razor?

Да.

A>Все эти @Parameters? Не, спасибо.

На Т4 мусора все равно будет больше. Ну и вместо @ там вроде ? можно.

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

AVK>>Надо уже с боями вместо Т4 пропихивать Razor
VD>Сдается мне, что как мета-тул он будет мало интересен.

Почему?

VD> Разве что как довесок к тому же Т4.

Вот уж как довесок к Т4 он точно не нужен.

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

AVK>>Это проблема далеко не только ПМ. Те же визиторы или мультиметоды от нее страдают в полный рост.

VD>У шаблона Посетитель такой проблемы нет. Там интерфейс определяет список альтернатив.

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

AVK>>Тут, скорее, надо просто ввести ключевое слово типа static, которое одновременно и sealed добавит и запретит создание свойств, которые ПМ обработать не сможет.

VD>Про статик не понял.

Ну есть такое ключевое слово static, которое навешивает sealed и запрещает нестатические члены.

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

ЕА>>

ЕА>>public var F()
ЕА>>{
ЕА>>  return new { Name = "A", Age = 10 };
ЕА>>}
ЕА>>

VD>Это не разумное предложение. Оно быстро сломает интелисенс в больших проектах. В методе может быть 100500 выражений, и методов может быть 100500. Для вывода типов придется протипизировать все их тела. А это самая долгая операция. Решарпер даже не парсит тела методов до того как пользователь к ним не обратится. А ты предлагаешь их все типизировать.

VD>Правильное решение для языка с хорошей поддержкой IDE будет возможность декларировать анонимные типы (превращение их в записи):
VD>

VD>public <string Name, int Age> F()
VD>{
VD>  return new { Name = "A", Age = 10 };
VD>}
VD>

Согласен, так меня тоже вполне устроит.

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

VD>Скорее это шаг в сторону. Если бы хотели сделать "все есть выражение", то не стали бы городить отдельный синтаксис для инициализации членов, а сделали бы универсальное решение.

Там не только инициализация, но и тело метода может быть.

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

VD>Хреново он ее решает. Неудобно. Лучше бы довели до ума анонимные типы. Сделали бы синтаксисх их декларации по месту, как у записей в ML-е. Например:
VD>

VD><int a; string b;> Foo()
VD>{
VD>  return new { a=42, b="text" };
VD>}
VD>

А такие типы между сборок должны шарится?

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

J>А такие типы между сборок должны шарится?

Не то чтобы "шариться". Их в рантайме нужно поддерживать. Для них должна быть реализована структурная эквивалентность. Тип объявленный в одной сборке должен быть совместим с таким же типом из другой сборки. Еще имеет смысл явное приведение сделать с кортежами и типами эквивалентными структурно, но имеющими другие названия полей.

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

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

J>>А такие типы между сборок должны шарится?

VD>Не то чтобы "шариться". Их в рантайме нужно поддерживать. Для них должна быть реализована структурная эквивалентность. Тип объявленный в одной сборке должен быть совместим с таким же типом из другой сборки. Еще имеет смысл явное приведение сделать с кортежами и типами эквивалентными структурно, но имеющими другие названия полей.

Хе. Структурная эквивалентность в .NET ?? Что то не верится -)

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

Z>Там не только инициализация, но и тело метода может быть.

Ну, вот и нужно было для тела выбрать "=", а инициализацию как-то по другому сделать.

Собственно мы так и сделали. NN по началу тоже хотел вариант

X : int { get; } = 42;

выбрать. Но мы подумали и решили, что это чревато проблемами.

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

AVK>Определять то определяет, но никак не запрещает подсунуть любого наследника. Точно такую же схему можно и в ПМ реализовать.

А причем тут наследники? Наследник будет переопределять поведение, но ты не сможешь вызвать Посетителя, если некоторое методы не реализованы, а с ПМ на открытых иерархиях это сделать элементарно. Иногда это даже бывает полезно. Но контроль понижается.

AVK>>>Тут, скорее, надо просто ввести ключевое слово типа static, которое одновременно и sealed добавит и запретит создание свойств, которые ПМ обработать не сможет.

VD>>Про статик не понял.

AVK>Ну есть такое ключевое слово static, которое навешивает sealed и запрещает нестатические члены.

А причем тут оно? Оно тут никаким боком.

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

VD>>Сдается мне, что как мета-тул он будет мало интересен.

AVK>Почему?

1. Нерасширяем. Поддерживает только шарп и васик.
2. Заточен на языковый сервис в IDE и компилятор.
3. Не позволяет вмешиваться в процесс парсинга/типизации.
4. Не имеет никаких средств ни для декомпозиции, ни для композиции кода.

Единственное его применение — это получение метаинформации о коде шарпа. Это очень узкая ниша. В реальных задачах придется сделать еще 100500 приседаний.

VD>> Разве что как довесок к тому же Т4.

AVK>Вот уж как довесок к Т4 он точно не нужен.

Ну, почему же? Т4 позволяет худо-бедно автоматизировать генерацию кода. Розлин — получить информацию о коде из проекта. Соединяем их вместе и получаем более интеллектуальную систему генерации кода, для тех кто боится использовать Немерл .

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

VD>Не то чтобы "шариться". Их в рантайме нужно поддерживать. Для них должна быть реализована структурная эквивалентность. Тип объявленный в одной сборке должен быть совместим с таким же типом из другой сборки.

С структурной эквивалентностью вылазят проблемы с рефлексией (начиная c type.AssemblyQualifiedName), сериализацией и с xml-комментариями. Решить можно, но я не уверен что затраты соответствуют выигрышу. Если уж передавать тип за границы сборки, то лучше объявить его явно и не возиться с "добавили поле в результат метода в сборке А -> всё упало в B".

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

I>Да, C# это не Немерле и никогда, слава богу, им не будет.

I>В С# с первой версии = для присваивания. => уже используется для лямбд, что бы блок с ретурном не писать. Так что всё очевидно

Для тебя. Но тут дело в тебе.

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

I>>Да, C# это не Немерле и никогда, слава богу, им не будет.

I>>В С# с первой версии = для присваивания. => уже используется для лямбд, что бы блок с ретурном не писать. Так что всё очевидно

VD>Для тебя. Но тут дело в тебе.

Не льсти себе — это вызывает слепоту.

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

J>Хе. Структурная эквивалентность в .NET ?? Что то не верится -)

А какие проблемы?

Они ее даже реализовали, но только для отдельных типов данных, для улучшения поддержки COM-а.

С точки зрения компьютера никаких типов данных не существует. Есть только области памяти. А типы данных — это их интерпретация. Структурная эквивалентность — это не более чем возможность использовать один "объект" вместо другого. МС без проблем может залудить это дело как только на то появится "политическая" воля.

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

S>С структурной эквивалентностью вылазят проблемы с рефлексией (начиная c type.AssemblyQualifiedName), сериализацией и с xml-комментариями.

Эти смелые утверждения нужно как следует обосновать. Я вот никаких проблем не вижу.

S>Решить можно, но я не уверен что затраты соответствуют выигрышу.

Нет там никаких особых затрат. И дотнет уже поддерживает ограниченную структурную эквивалентность для комовских типов.

Проверка структурной эквивалентности типов производится в момент загрузки сборок/типов. Далее для нужд рефлексии и т.п. используем первый попавшийся тип, а остальные позволяет передавать там где ожидаются их структурные эквиваленты.

S>Если уж передавать тип за границы сборки, то лучше объявить его явно и не возиться с "добавили поле в результат метода в сборке А -> всё упало в B".

Это физически невозможно. Будет "брильянтовая проблема". В одной библиотеке объявляем тип. Другой объявляем тот же тип. Что делать приложению которое хочет использовать обе библиотеки и этот тип? Единственный выход — объявить свой тип, проверить, что он структурно эквивалентен двум других типам из других сборок и позволить использовать один тип вместо другого.

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

I>Не льсти себе — это вызывает слепоту.

Я то тут причем? Ты уж как-нить со своей слепотой сам разбирайся.

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

I>>Не льсти себе — это вызывает слепоту.

VD>Я то тут причем? Ты уж как-нить со своей слепотой сам разбирайся.

А кто по твоему, не видит что = это присваивание ?

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

VD>1. Нерасширяем. Поддерживает только шарп и васик.

Пфф.

VD>2. Заточен на языковый сервис в IDE и компилятор.

Нет.

VD>3. Не позволяет вмешиваться в процесс парсинга/типизации.

Т4 тоже не позволяет.

VD>4. Не имеет никаких средств ни для декомпозиции, ни для композиции кода.

Имеет.

VD>Единственное его применение — это получение метаинформации о коде шарпа.

Ты, видимо, о чем то о своем, а не про razor.

AVK>>Вот уж как довесок к Т4 он точно не нужен.
VD>Ну, почему же? Т4 позволяет худо-бедно автоматизировать генерацию кода. Розлин — получить информацию о коде из проекта.

Ну понятно, как обычно читаем по диагонали. Не розлин, а razor.