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


VD>Должно быть возможно определять такие типы явно. Нечто вроде:
Так, а с таким вариантом всё работать, про него я не подумал

Для полной красоты потребуется способ прописывать using-и на уровне сборки + генерация в рантайме TypeInfo с пропиской типа в mscorlib и принципиально большинства косяков не будет.

Я зачем-то зациклился на анонимных типах как они есть в текущем шарпе. Вот их, как не крути, использовать неудобно.

Короче говоря, тут я сливаюсь, возражения забираю

S>>С явным описанием типов у нас может быть только одно место, где мы ломаем совместимость сборок — собственно, само описание типа. С структурной эквивалентностью мы расширяем его до любой публичной сигнатуры, возвращающей анонимный тип. Затраты на тестирование возрастают соответственно.
VD>Расшифруй плиз свои мысли.
VD>За одно подумай почему с сигнатурами функций нет тех же проблем и какая разница между ними и записями. Вот чем отличается изменение: ...

Так сравнивать надо не параметры vs анонимные типы, а анонимные типы vs обычные. В обычном варианте добавление/удаление неиспользуемых полей ничего не ломает *(пока у нас тип — не структура, да и то после перекомпиляции зависимых сборок всё будет ок).
С анонимными типами любое изменение публичной сигнатуры приводит к проверке всего зависимого кода. Из-за лёгкости протаскивания анонимных типов через методы эта зависимая область будет очень большой. Одно но: это относилось к синтаксису что предлагали выше по теме — с автоматическим выводом возвращаемого значения, аля

public var X() { return new { A = 1, B = 2 }; }

// ...

public var Y() { return X(); }

Если по-прежнему явно указывать возвращаемый тип — такой проблемы не будет конечно.

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



VD>В метаданных нужно всего лишь отразить факт того что тип рассматривается как структурно эквивалентный. Это можно сделать даже простым атрибутом.

VD>Вот что должно измениться, так это поведение фремворка. Но тут проблем возникнуть не должно.

Можно Ввести структуры по типу Action<T,T1,R>

struct АнонимнаяСтруктура<T1,T1,T3>
{
   T1 первоеПоле;
   T2 второеполе;
   T3 третьеПоле;
}

А вот в при создании анонимного типа уже для каждого поля прикрутить атрибутами реальное наименование полей.

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

_NN>А как знать что внутри при вызове метода ?
К моменту вызова метода он уже скомпилирован, и компилятор заменил var на вполне определённый типа.

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

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

S>>Потому уверен что обсуждается структурная эквивалентность только анонимных типов.

AVK>Влад, имхо, как раз таки обсуждает

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

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

Нужно соглашение по которому фреймворк будет считать типы одинаковыми и позволять передавать один вместо другого.

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

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

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

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

S>>не понял. Для того что бы добавить еще одно или 10 полей к результату, выкидывать не надо.
S>Надо. Т.к. сборки пользователей завязаны на старую сигнатуру и их никто перекомпилировать после каждого сервис-пака не будет.
В этом отношениии выкидывание точно так же приведет к перекомпилированию.

S>>А связываемся мы с этим затем, что бы мы могли делать объявления методов, совместимые с анонимными типами. Linq-у это здорово поможет.
S>Не поможет. Добавляем всего-то
S>

S>var a = 
S>  from y in x.Y
S>  from z in y.Z
S>  let a = new { A = y, B = z }
S>  group new { y, S = a } by a into g
S>  select SomeFunc(g.Key, g.First());
S>

S>и
S>

S>void Foo({ A:string, B: int} value);
S>

S>превращается в "мамадорогая, зачем я с этим связался " Смысл анонимных типов — в отсутствии необходимости описывать тип. Как только мы описали тип — всё, можно его вытащить в явное описание и не страдать фигнёй.
Не вижу тут мамыдорогой
Вот допустим, хочу параметризовать Linq2Sql запрос предикатом, полученным в параметре метода. Как мне поможет явное описание типа? По-моему никак. Тут даже фигней не пострадать. Только впихивать все возможные предикаты в тело метода, где я строю запрос и выбирать предикаты по маркеру/идентификатору. С наличием возможности использовать анонимные типы вовне можно будет передавать Expression с предикатом извне и передавать результат запроса наружу.

S>Ну, или оставить как есть и проверять сигнатуры вручную при каждом мерже исправлений
S>Альтернативщину вида "пишем Foo(var a) — компилятор разрулит" лучше оставить языкам с рантайм-верификацией типов, для шарпа это всё-таки изврат
У F#-а ведь нет рантайм верификации типов?

S>>Я не вижу здесь причин для того что бы делать типы вложенными.
S>Проектирование мейнстримного ЯП должно осуществляться чуть по другим критериям Просто потому, что если дырка есть — её обязательно используют и она так и останется, чисто из соображений совместимости.
А причем тут вложенность?

S>Навскидку — ApplicationException/SystemException, Delegate/MulticastDelegate, AppDomainSetup.ShadowCopyFiles = "True" (угу, строковая константа), ковариантные массивы, IEnumerator в виде структуры, delegate.BeginInvoke() и прочее-прочее так и остались с нами спустя 11 лет после выхода первого фреймворка (ёшкин кот, как время летит!).

S>Так что лучше не создавать себе проблем, чем потом геройски с ними бороться.
Верно. Но я пока даже их не увидел.
Я не предлагаю такие изменения в C# 6.0 и даже 9.0. Я просто для себя пытаюсь понять, почему принципиально нет? Где проблема?

S>>Объявляем параметр примерно так
S>>void Foo({ A:string, B: int} value);
S>Оно будет работать только для совсем примитивных вариантов. Чуть посложнее — и мы завязнем в сверке сигнатур после каждой правки.
Завязнем. Но лучше завязнуть в принципиальной возможности, чем без таковой. Имхо.
В F# есть констрейнты на наличие у дженерик типа свойств. Можно было бы заюзать что-то подобное.

S>>и передаем. Все что имеет совместимый тип должно передаваться без вопросов. Неочевидным будет лишь value.GetType().
S>А у мейнстрим-языка нет права на "всё ок, но тут неочевидным будет". Берём шанс получить ошибку (довольно высокий, учитывая средний уровень по палате), умножаем на количество пользователей — получаем дофигаллион потраченного времени и хороший плевок себе в карму как разработчику.
Мы уже имеем дофигаллион потраченного времени. И продолжаем его тратить. Развитие языка делается именно для того что бы тратить его меньше.
yield-ы и async-и — здоровенный плевок в карму. Но те, кто насобачился ими пользоваться, получили отличный инструмент.

S>>Это ведь уже как-то работает с анонимными типами?
S>Да, но только потому, что у нас нет граблей с изменением CallSite от запуска к запуску. Грубо говоря, метод T<>anon.get_A не должен прыгать из сборки в сборку
Отлично, пусть висит в System.Runtime.CompilerServices.CallSite

S>>Тут неоднозначность раньше возникает. Уже GetType() вернет неизвестно что.
S>Ага. Но пользователю от этого не легче
Если честно, то в голову не приходят даже сценарии использования GetType для анонимных типов (кроме линк провайдеров). Их можно выдумать, но зачем? А линк провайдеру должно быть пофигу, если типы эквивалентны.

S>>Можно обсудить и другие варианты. Например, генерацию кода для конвертации совместимых типов вместо их подмены рантаймом.
S>А это уже реальнее. Тогда надо вводить явное приведение с ducktyping, аля
S>

S>var x = y castas ISomeFeature; // y не реализует ISomeFeature, в x попадает обёртка с ссылкой на y, реализующая ISomeFeature
S>

S>Минусы конечно будут, например — сложность с возвращением исходной ссылки на y, зная только x.
S>Как плюс — мы вообще освобождаемся от проблемы "как обозвать анонимный тип чтобы оставить его анонимным". Ну, и не надо трогать рантайм — всё можно сделать силами компилятора.
Это интересно само по себе. Но я подразумевал всего лишь что-то типа ILMerge под капотом при передаче совместимых анонимных типов. И это тоже можно решить без рантайма.

Здравствуйте, Аноним, Вы писали:

Судя по всему, у дизайнеров языка нет цели — они сами не знают, к чему стремятся и что оптимизируют (это можно сказать не только про C#, но и про многие другие языки, это какой-то бич всей области разработки языков). Пока что курс намечается на то, что язык будет все более сложным для изучения и чтения и будет превращаться в концептуально-синтаксическую помойку, что не может не огорчать, так как C# первое время подавал пример того, как надо подходить к разработке новых языков.

Мне что-то кажется, что этот уклон в сторону примешивания фич и синтаксиса из функциональных языков идет от Липперта, а не от Хейлсберга. Возможно, этим двум людям вообще стоило бы разрабатывать два разных языка.

Здравствуйте, Аноним, Вы писали:

А>Мне что-то кажется, что этот уклон в сторону примешивания фич и синтаксиса из функциональных языков идет от Липперта, а не от Хейлсберга. Возможно, этим двум людям вообще стоило бы разрабатывать два разных языка.

Липперт уже год как не работает в MS.

Здравствуйте, Ziaw, Вы писали:
Z>Ты имеешь в виду другой конструктор?
Я так понял, что тот же самый:

public class Person(string name) 
{
  if (string.IsNullOrEmpty(name))
    throw new ArgumentException("name", "name must be a non-empty string!");
}

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

S>Можно Ввести структуры по типу Action<T,T1,R>

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

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

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

S>>Можно Ввести структуры по типу Action<T,T1,R>

VD>Это будет кортеж. Оно и так есть. Весь смысл в именованных полях.
Ну можно сделать перегрузку из кортежа в класс и обратно.
Например есть класс содержащий кортеж и свойства которые обращаются к этому полю.
Тогда приведение типа будет только в копировании ссылки на кортеж

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

S>Так сравнивать надо не параметры vs анонимные типы, а анонимные типы vs обычные.

Зачем? Это такая же "зациклиность". Ты просто привык так думать. Если взглянуть на это под другим углом, то становится понятным, что список параметров ничем не отличается от возвращаемого значения. у нас есть функция которая определяется двумя записями входящей и исходящей. Можно даже вот такую запись для функциональных типов придумать:

<int x, int y> -> <string name, bool isMale>

вместо идиотских делегатов.

Тоже самое для кортежей:

<int, int> -> <string, bool>

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

S>С анонимными типами любое изменение публичной сигнатуры приводит к проверке всего зависимого кода.

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

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

1 в 1 как со списком параметров.

S>Одно но: это относилось к синтаксису что предлагали выше по теме — с автоматическим выводом возвращаемого значения, аля
S>

S>public var X() { return new { A = 1, B = 2 }; }
S>public var Y() { return X(); }
S>

S>Если по-прежнему явно указывать возвращаемый тип — такой проблемы не будет конечно.

Ну, какой смысл его рассматирвать? Я сразу сказал, что глобальный вывод типов — это плохое решение для языка который хочет обладать хорошей поддержкой IDE. Это просто другая проблема.

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

Кстати, логично было бы позволять задавать имя и для атомарного возвращаемого значения функций:

<int index> IndexOf(T value);

Это облегчило бы IDE создание хороших имен для переменных принимающих значение функции и сделало бы язык более единообразным.
Естественно, что это должно быть необязательным. Так же как и должно быть возможно забить на мена и сделать вместо записи кортеж.

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

S>Ну можно сделать перегрузку из кортежа в класс и обратно.
S>Например есть класс содержащий кортеж и свойства которые обращаются к этому полю.
S>Тогда приведение типа будет только в копировании ссылки на кортеж

Это все никому не нужные приседания. С кортежами работу можно организовать без переделки рантайма. Для полноценной поддержки записей (правильных анонимных типов) нужно менять рантайм. Только это изменение сильно проще нежели себе представляют многие.

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

Речь шла о фиче:

А>>//primary constructors —
А>>public class Point(int x, int y) { }

Влад сказал, что это аналог немерловой макры Record.

Это аналогично немерловой макре Record, но несколько более гибко, так как можно реализовать логику в кострукторе.

Насколько я понимаю, в primary constructor, логику реализовать не получится. Вот и хотел уточнить, что он имел в виду.

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

Z>Насколько я понимаю, в primary constructor, логику реализовать не получится.
ну вот это как раз большой вопрос. ПОтому что в том же F# как раз можно реализовать логику в праймари конструкторе. http://msdn.microsoft.com/en-us/library/dd233192.aspx

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

Z>>Насколько я понимаю, в primary constructor, логику реализовать не получится.
J>ну вот это как раз большой вопрос. ПОтому что в том же F# как раз можно реализовать логику в праймари конструкторе. http://msdn.microsoft.com/en-us/library/dd233192.aspx

Есть. И не только в F#. Но представленный синтаксис для C# выглядит так, как будто нельзя.

a есть хоть какая-то инфа когда его ждать?

фичи вкусные вполне, хоть все больше и "сахарные"

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

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

S>>Ну можно сделать перегрузку из кортежа в класс и обратно.
S>>Например есть класс содержащий кортеж и свойства которые обращаются к этому полю.
S>>Тогда приведение типа будет только в копировании ссылки на кортеж

VD>Это все никому не нужные приседания. С кортежами работу можно организовать без переделки рантайма. Для полноценной поддержки записей (правильных анонимных типов) нужно менять рантайм. Только это изменение сильно проще нежели себе представляют многие.

Если Анонимный класс сделать наследником Кортежа,а в метаклассе (Type) будет содержать хэш соединенных строк полей, то и может и рантайм менять не надо. Так при приведении сначала сравнивается базовый класс, а затем Хэш полей и если они совпадают то считаются одинаковыми

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

VD>Мне, после третьей строки, просто не захотелось на это тратить свое время.

Это все лирика. А факт состоит в том, что ты не читаешь сообщения, на которые отвечаешь.

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

Напрягает. При том что он не далеко не настолько избыточный, как Т4 с его громоздким хмлем.

AVK>>Но если не шашечки а ехать, то разор сильно удобнее.
VD>Это ни шашечки, и не ехать. Это костыли. Ехать на них не выйдет.

Кому как. Пока, из обсуждаемых здесь технологий, ковыляет совсем не разор.

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

S>Вот допустим, хочу параметризовать Linq2Sql запрос предикатом, полученным в параметре метода. Как мне поможет явное описание типа? По-моему никак. Тут даже фигней не пострадать. Только впихивать все возможные предикаты в тело метода, где я строю запрос и выбирать предикаты по маркеру/идентификатору. С наличием возможности использовать анонимные типы вовне можно будет передавать Expression с предикатом извне и передавать результат запроса наружу.

Ничего не понял. Сейчас предикаты в where прекрасно передаются без описанного тобой ужаса. И какая связь между типом предиката и возвращаемым результатом?

S>>Ага. Но пользователю от этого не легче
S>Если честно, то в голову не приходят даже сценарии использования GetType для анонимных типов

Да элементарно. Создаем в компоненте свойство или коллекцию с анонимным типом, а потом пытаемся посмотреть что PropertyGrid показывает. Или, как тут уже много раз упоминалось, просто сериализуем. Я уж не говорю про то, что кодогенерация во всяких мапперах и linq2db с типами-нетипами резко усложняется, потому что этот кейс придется обруливать чуть менее чем везде.

S>А линк провайдеру должно быть пофигу, если типы эквивалентны.

Чтобы линк-провайдеру все было пофигу, IL должен быть у всех типов идентичный. А для этого обязательно корежить рантайм и преизрядно.

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

Продемонстрируй на псевдокоде.

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

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

Текущий анонимный — это совершенно честный тип без какой либо химии в рантайме. Но анонимные типы в разных сборках — разные, несовместимые между собой даже при полном совпадении сигнатуры.