Здравствуйте, adontz, Вы писали:
A>Учитывая что row level security применили к дереву, опциональное наследование как раз очень органично выглядит.
Совершенно верно, Рома, выглядит. Я надеюсь, ты в курсе, что появилось оно не сразу?

A>CREATOR_OWNER это вообще сделано для совместимости со всякими Юниксами.

Нет, Рома, это сделано из соображений уменьшения затрат на администрирование. Чтобы пользователи могли хоть как-то совместно пользоваться фолдерами без постоянного вмешательства админа.
A> Есть ещё CREATOR_GROUP, есть "главная" группа у доменных пользователей. Самому Windows права доступа на псевдоним CREATOR_OWNER не нужны, вполне подошёл бы механизм привелегий.
Ага. Ну расскажи мне, как при помощи механизма привилегий дать людям возможность создавать новые документы в некоторой папке, но при этом по умолчанию не иметь возможности править документы друг друга.

A>Ой, да ладно. Вот так всё плохо и никто не придумал ничего существенно лучше?
Придумал. Тебе про это как раз рассказывают. А ты упираешься.

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

A>>Ну покажи пример
S>Очень просто. Вот у тебя были сущности A->B->C<-D.
S>Клиент запросил A, ты закачал A->B->C. Теперь клиент удалил C, убрав в B ccылку. Всё в порядке — у него ссылок на C больше нет, ссылочная целостность не нарушена. При коммите выяснится, что упс — есть еще D, про которого твой клиент ничего не знает.

Такая проблема не специфична для моего подхода. В твоём случае D (или только ссылку D->C) могли создать после запроса и твои Linq-образные запросы не помогли бы. Тут, и вообще по жизни, правильно вообще ничего из базы не удалять, а только помечать флажками: удалено, старая версия, и т.д.

A>>Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.
S>Не очень понятно, что такое "правильно". Если объект, на основе которого скидка рассчитывается, изменился, то ничего правильного не получится.

Правильно в том смысле что в какой момент времени это было правильно.

A>>Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает.
S> Я по прежнему жду доказательства того, что именно такой кэш себя оправдывает. По сравнению с более другими стратегиями кэширования.

Формального строго доказательства экономии трафика у меня нет, по моему я этого и не скрывал и никогда не представлял экономию трафика как главное благо. Что касается архитектуры вообще, то мы может обсуждать негативные моменты и их последствия. Если мы будем давать субъективную разную оценку серьёзности негативных последствий то к общему мнению не придём, что и наблюдается.

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

Если бы у нас была точная наука, мы бы с тобой не спорили.

S>Ни понятия корректности, ни допустимости ты определить не хочешь. Никаких внятных утверждений доказывать не собираешься. И даже пример проблемы привести не можешь. О чём мы вообще говорим?

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

A>>Берёт новые заказы, просматривает старые заказы (не старше месяца), считает прибыль и остаток мобильного склада (если есть мобильный склад).
S>Угу. Твой кэш заточен на то, чтобы ровно эти операции не требовали обращения к серверу, так?

Кеш заточен на предоставление минимально необходимого ссылочно-целостного подмножества БД. Что входит в необходимые данные, конечно же, определяется операциями над этими данными.

A>>Антон, а что тут доказывать? И сам объём данных меньше, потому что нет дублирования, и необходимость в обновлении меньше.
S>Здрасте, приехали. С чего объем данных-то меньше? В твоём примере было про A->B->C, и про D->E. Неужели же это будет меньше, чем только A и D? Ну давай, докажи.

А ты отвлекись от одной операции. Для одной операции тебе надо A и D, для другой B, C, D, для третьей A и B. Если кешировать результаты запросов, дублирование будет обязательно.

A>>Я думал, ты под актуальностью понимаешь синхронность с версией в центральной БД.
S>Это без транзакционности, естественно, невозможно гарантировать вообще никак.

Было бы здорово если бы ты ещё объяснил что всё это время подразумевал под актуальностью.

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

A>>CREATOR_OWNER это вообще сделано для совместимости со всякими Юниксами.
S>
S>Нет, Рома, это сделано из соображений уменьшения затрат на администрирование. Чтобы пользователи могли хоть как-то совместно пользоваться фолдерами без постоянного вмешательства админа.

Антон, объясни мне пожалуйста в чём принципиальная разница между заданием пользователя Sinclair как CREATOR_OWNER файла и заданием Full Access для CREATOR_OWNER и заданием Full Access для Sinclair?

A>> Есть ещё CREATOR_GROUP, есть "главная" группа у доменных пользователей. Самому Windows права доступа на псевдоним CREATOR_OWNER не нужны, вполне подошёл бы механизм привелегий.
S>Ага. Ну расскажи мне, как при помощи механизма привилегий дать людям возможность создавать новые документы в некоторой папке, но при этом по умолчанию не иметь возможности править документы друг друга.

По уму надо делать hook script, CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.

A>>Ой, да ладно. Вот так всё плохо и никто не придумал ничего существенно лучше?
S>Придумал. Тебе про это как раз рассказывают. А ты упираешься.

Что-то ваша реализация пока нигде себя не оправдала.

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

A>Надо заметить, что вне зависимости от подхода, если есть желание работать только с актуальными данными, то придётся помучаться. Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает.

То что данные строго разделены между пользователями — очень сильное допущение. Фактически все сводится к секционированию БД на области, в которых нету конкурентного доступа. Естественно таким образом каждую секцию выгоднее всего держать "ближе" к приложению — в локальной реплике. Я бы для таких целей SQL CE использовал, или SQL Express c user instance если нужны фичи полновесной РСУБД. То что не укладывается в такую схему можно дергать с сервера через веб-сервисы.

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

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

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

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

A>>>Ну покажи пример
S>>Очень просто. Вот у тебя были сущности A->B->C<-D.
S>>Клиент запросил A, ты закачал A->B->C. Теперь клиент удалил C, убрав в B ccылку. Всё в порядке — у него ссылок на C больше нет, ссылочная целостность не нарушена. При коммите выяснится, что упс — есть еще D, про которого твой клиент ничего не знает.

A>Такая проблема не специфична для моего подхода. В твоём случае D (или только ссылку D->C) могли создать после запроса и твои Linq-образные запросы не помогли бы. Тут, и вообще по жизни, правильно вообще ничего из базы не удалять, а только помечать флажками: удалено, старая версия, и т.д.
Не надо никаких флажков. Достаточно не делать операция вставки\удаления в отсоединенный набор данных.

A>>>Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.
S>>Не очень понятно, что такое "правильно". Если объект, на основе которого скидка рассчитывается, изменился, то ничего правильного не получится.
A>Правильно в том смысле что в какой момент времени это было правильно.
Когда? Год назад?
Рассчеты скидок должны быть правильными "сейчас".

A>>>Я показал природу проблемы. Неправильно считаться может всё что угодно. Самый простой пример — скидки, бонусы. При желании можно придумать ещё, у нас же не соревнование в богатстве фантазии.
S>>Нет, у нас точная наука.
A>Если бы у нас была точная наука, мы бы с тобой не спорили.
Наука у нас точная, а вот точных методов анализа и доказательств не хватает.

Здравствуйте, adontz, Вы писали:
A>Антон, объясни мне пожалуйста в чём принципиальная разница между заданием пользователя Sinclair как CREATOR_OWNER файла и заданием Full Access для CREATOR_OWNER и заданием Full Access для Sinclair?
В том, что первое работает автоматически, а второе должен выполнить админ для каждого файла.

A>По уму надо делать hook script,
о-о-о, начинается. Вот она — великая мощь RLS. Нужен хук скрипт. Цитирую одного человека по поводу этого:

Это код и это не гибко.

A> CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.
Да-да. То-то я смотрю это бессмысленное решение применяется в 100% инсталляций. Добро пожаловать в реальный мир.

A>Что-то ваша реализация пока нигде себя не оправдала.
Твоя пока тоже

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

G>Для автоматизации коллективной работы (любые CRM, ERP, систкемы документооборота) такая схема не подойдет. Там в большенстве процессов участвует много людей (менеджеры, кураторы, исполнители), с пересекающимися обязанностями, а самое главное они работают с одними и теми же данными (клиентами, договорами).

Напротив, если бы вместе работала большая группа людей, она была бы неуправляема. Тип данных может быть одинаковый, а вот секционирование всё равно выходит. В CRM конкретные люди решают разные типы проблем или работают с небольшим количеством клиентов, в документообороте конкретные люди оформляют разные типы документов.

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

G>Не надо никаких флажков. Достаточно не делать операция вставки\удаления в отсоединенный набор данных.

Да, я помню что ты любишь удалять из БД

A>>Правильно в том смысле что в какой момент времени это было правильно.
G>Когда? Год назад?

Недавно, иначе кеш не имеет смысла. Причём настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора.

G>Рассчеты скидок должны быть правильными "сейчас".

Это можно сделать только на сервере.

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

A>>По уму надо делать hook script,
S>о-о-о, начинается. Вот она — великая мощь RLS. Нужен хук скрипт. Цитирую одного человека по поводу этого:
S>

Это код и это не гибко.

Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.

A>> CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.
S>Да-да. То-то я смотрю это бессмысленное решение применяется в 100% инсталляций. Добро пожаловать в реальный мир.

Антон, ты живёшь в альтернативной реальности. Во всех (не моих!) инсталляциях которые я видел пользователям делают личные папочки на сервере, на которые редиректится My Documents, Desktop и т.д., а CREATOR_OWNER вообще не используется. Обмен документами происходит либо через почту/мессенджер, либо черех спецпапку Inbox в которой у чужаков только право CREATE. Надо перетащить файл поверх папки и он запишется внутрь, зайти нельзя.

A>>Что-то ваша реализация пока нигде себя не оправдала.
S>Твоя пока тоже

Ну да, до вас прав доступа вообще не было.

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

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

G>>Для автоматизации коллективной работы (любые CRM, ERP, систкемы документооборота) такая схема не подойдет. Там в большенстве процессов участвует много людей (менеджеры, кураторы, исполнители), с пересекающимися обязанностями, а самое главное они работают с одними и теми же данными (клиентами, договорами).

A>Напротив, если бы вместе работала большая группа людей, она была бы неуправляема. Тип данных может быть одинаковый, а вот секционирование всё равно выходит. В CRM конкретные люди решают разные типы проблем или работают с небольшим количеством клиентов, в документообороте конкретные люди оформляют разные типы документов.

Тебе так хочется в это верить?
Но так не выходит. Весь прикол в том что в CRM можество людей отвечают за работу с одним клиентом, так же как в документоообороте множество людей работают с одним документом.
Попытка внедрить туда раздеоление данных только усложняет работу.

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

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

A>>>Правильно в том смысле что в какой момент времени это было правильно.
G>>Когда? Год назад?
A>Недавно, иначе кеш не имеет смысла. Причём настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора.
Ну, конкретнее, сколько времени оценка будет правильной?
Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза?

G>>Рассчеты скидок должны быть правильными "сейчас".
A>Это можно сделать только на сервере.
Тогда зачем что-то делать на клиенте, если корректный результат возможен только при вычислении на сервере?
Ведь все эти кеши, запреты удаления, прочая муть только от того что хочется что-то безопасно делать на клиенте.

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

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

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

A>>>По уму надо делать hook script,
S>>о-о-о, начинается. Вот она — великая мощь RLS. Нужен хук скрипт. Цитирую одного человека по поводу этого:
S>>

Это код и это не гибко.

A>Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.

Вопрос в том как сделать максимум кода декларативным, а не то что ты написал.

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

A>>Напротив, если бы вместе работала большая группа людей, она была бы неуправляема. Тип данных может быть одинаковый, а вот секционирование всё равно выходит. В CRM конкретные люди решают разные типы проблем или работают с небольшим количеством клиентов, в документообороте конкретные люди оформляют разные типы документов.

G>Тебе так хочется в это верить?
G>Но так не выходит. Весь прикол в том что в CRM можество людей отвечают за работу с одним клиентом, так же как в документоообороте множество людей работают с одним документом.
G>Попытка внедрить туда раздеоление данных только усложняет работу.
G>Ты видимо как раз занимаешься торгово-закупочтым софтом для малых огранизаций, поэтому думаешь что именно так везде работает.
G>Я, к счастью, успел поучаствовать в разработке разного софта.

gandjustas, если ты себе не представляешь как выделять данные в кеш, то так и скажи. Дистрибуцию я приводил как общепонятный контекст, уж точно я не только этим занимался. Твой пафос неуместен.

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

A>Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.
Совершенно верно. И data-driven — это не отдельный DACL, а безопасность, построенная на предикатах. Где нет страха, что хук скрипт не отработал, и при смене правил нет необходимости бегать по всем объектам и проверять их DACL.

A>>> CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.
S>>Да-да. То-то я смотрю это бессмысленное решение применяется в 100% инсталляций. Добро пожаловать в реальный мир.

A>Антон, ты живёшь в альтернативной реальности. Во всех (не моих!) инсталляциях которые я видел пользователям делают личные папочки на сервере, на которые редиректится My Documents, Desktop и т.д., а CREATOR_OWNER вообще не используется.
Рома, не тренди.
Читать здесь. Creator/Owner подчеркнуть, или сам найдешь?
Посмотри также насчет того, что поменяли в висте на эту тему. Аналогичная фигня — дефолтные DACL подправили так, чтобы соответствовать реальным сценариям.
A>Ну да, до вас прав доступа вообще не было.
Головой просто думать надо, головой.

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

A>>Недавно, иначе кеш не имеет смысла. Причём настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора.
G>Ну, конкретнее, сколько времени оценка будет правильной?

Я уже написал, ты не удосужился прочесть. "настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора".

G>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза?

А в чём проблема-то? Кеш обновляется не по таймеру.

A>>Это можно сделать только на сервере.
G>Тогда зачем что-то делать на клиенте, если корректный результат возможен только при вычислении на сервере?
G>Ведь все эти кеши, запреты удаления, прочая муть только от того что хочется что-то безопасно делать на клиенте.

Нет. Запрет удаления с кешем совсем не связан. Ты ничего не понял и решил свалить всё в кучу. В Active Directory, например, объекты удаляются в распределённой системе. И ничего, всё работает. Запрет удаления это не ограничение вызванное использованием кеша, это совершенно отдельная песня.

Далее. Корректный результат при добавлении данных всегда возможен на сервере. Для некоторых задач он возможен и на клиенте. Кроме того есть отчёты которые можно снимать с кеша (история операций). Кроме того, постоянное соединение с сервером никто не обещал.

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

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

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

A>>Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.
G>Вопрос в том как сделать максимум кода декларативным, а не то что ты написал.

Ща мы в очередной раз узнаем что Немерле немеряно рулит? По-моему, очевидно что декларативное опписание это ещё один язык, и далеко не самый удобный для понимания, отладки и т.д. Для администрирования лучше data driven.

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

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

A>>>Напротив, если бы вместе работала большая группа людей, она была бы неуправляема. Тип данных может быть одинаковый, а вот секционирование всё равно выходит. В CRM конкретные люди решают разные типы проблем или работают с небольшим количеством клиентов, в документообороте конкретные люди оформляют разные типы документов.

G>>Тебе так хочется в это верить?
G>>Но так не выходит. Весь прикол в том что в CRM можество людей отвечают за работу с одним клиентом, так же как в документоообороте множество людей работают с одним документом.
G>>Попытка внедрить туда раздеоление данных только усложняет работу.
G>>Ты видимо как раз занимаешься торгово-закупочтым софтом для малых огранизаций, поэтому думаешь что именно так везде работает.
G>>Я, к счастью, успел поучаствовать в разработке разного софта.

A>gandjustas, если ты себе не представляешь как выделять данные в кеш, то так и скажи. Дистрибуцию я приводил как общепонятный контекст, уж точно я не только этим занимался.
Я отлично знаю как данные в кеш выедлять.
Только ты под кешем понимаешь только локальную реплику. Поэтому непонимаешь что другие тебе говорят.
А самое главное что ты даже толком не можешь сказать зачем тебе локальная реплика, только пытаешься свести все к одному сценарию — "каждый пользователь работает только со своим куском данных".

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


V>>Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации.
EC>Это в каком месте полиморфизм по алгебраическим типам динамически типизирован?

В месте определения значения дискриминатора, вестимо. Конкретно в Хаскеле — в соотв. строке матчинга.

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

S> Правда, меня пока что забанили в том списке — на выходных лежала даже гуглопочта нашего сайта, за что меня и тово, лишили доступа к телу.
Та же фигня. Попросил Лизу переключить меня на другой мэйл, но пока молчит...

S>Не думаю, что его слова там как-то особенно непонятны.
Собственно Меер в той команде уже лет несколько, так что...

S> Чуваки из CLR — вполне вменяемые. Их главное убедить, что что-то вообще нужно. Потому что их работа — это говорить "but you can achieve virtually the same result by using {workaround description}" — и это правильно. Иначе бы в CLR было бы столько навоза — не разгребешь
+1

VD>И что потом они это дело поправят. Но время идет и что-то не видно, чтобы его слова воплощашись в дело. Новая версия дотнета с новым CLR уже во всю тестируется, но о развитии анонимных типов или хотя бы о доработке CLR ничего не слышно.
Проблема в том, что в этой версии они категорически хотят менять компилятор по минимуму и основные изменения будут в C# 5. В плоть до того, что выкидываются вещи, которые еще полгода назад обещались обязательно реализовать.

S>Ну, там пока в основном другие MVP отжигают; народ из команды как-то так, значительно менее активен. Но я попробую.
Да, отжигают они там неподецки, от некоторых идей в дрож бросает.. ))

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

S>Операторы биндятся в компайл-тайме на основе статически известного типа аргументов. Поэтому нужно убедиться, что ни в одном из сценариев компилятор не потеряет тип.
S>...Дык надо понять, что такое "структура". Набор полей? Набор свойств?

Набор, порядок следования, смещения, области видимости и имена полей.
Отдельный вопрос нужны ли вообще типу поддерживающему структурную идентичность что-то выходящее за пределы интефейса object. Разве что им бы не помешала реализация IComparable<T> и IEquatable<T>.
В прочем, учитывая проблемы с видимостью членов возможно должно быть полное совпадение интерфейса: полей, публичных методов и свойств, реализуемых интерфейсов.

Для реализации записей достаточно будет если у объекта все поля будут публичными (доступными только на чтение). В прочем, у анонимных типов это уже не так. В них проявляется весь маразм ООП. Наружу торчат свойства, а свойства скрыты. Но это уже детали реализации. Если принять правила:
1. Структурно-эквивалентными объектами могут быть объекты одного супер-типа (struct, class и т.п.).
2. Объекты должны быть помечены специальным атрибутом содержащим Guid.
3. У объектов должны полностью совпадать структура полей и интерфейс (возможно можно наплевать на не публичные методы и своейства).
4. Тип должен быть запечатанным (sealed).
то можно прозрачно обеспечить структурную эквивалентность для весьма разных типов.

S>Ну да, вот Nullable пришлось специальным образом хардкодить в рантайме, чтобы гарантировать корректные результаты при анбоксинге null и прочие весёлости.

Это немного другое. Там проблемой было неинтуитивная семантика. В случае структурной эквивалентности таких проблем нет. Кстати, в ML-клонах решена проблема null. Это исключает целый класс ошибок. Очень советую познакомиться.

S>Я nen подумал о том, что для неизменяемых типов нужна специальный Property pattern.

S>В CLR встроена возможность обозвать пропертью пару методов с сигнатурами void SetXXX(T value), T GetXXX().
S>Для immutable-типов void SetXXX не подходит. Зато подойдет метод SetXXX, который возвращает новый экземпляр, который отличается от старого только значением свойства.
S>Ну, и собственно сами проперти должны иметь тот же смысл.
S>То есть мы пишем как-то так:
S>

S>var newDate = GetDate().Days += 1;
S>

Это отдельный разговор. Ты изобрел велосипед. В ML-клонах есть подобная функциональность. Выглядит немного по другому, но суть та же.

VD>>Это все проверено сто раз в функциональных языках. Даже нехилая теория под это дело подведена.
S>Ну так в этих языках нет проблемы интероперабельности с CLR.

Это у CLR есть проблема в поддержке этих языков. И уж одно это является его недостатком. Ведь многоязычность декларирована, а по факту CLR может напрямую поддерживать только C# и VB.

S>Да, мелочевка — в том числе и поддержка туплов. Но в основном люди страдают ерундой.

Я так и думал. Потому и ребятам из МС плевать на свое детище. Один фиг куча недоучек ничего не заметит.

S>Например, некоторые C# MVP из Калифорнии искренне полагают, что switch("test") порождает словарь строк при каждом проходе.

Ну, дык и гнат его из MVP.