Здравствуйте, VladD2, Вы писали:
Z>>А то, что внутри модели становится возможно передавать анонимные классы это побочный плюс. Даже без них фича нужная, хотя она работает и с ними.
VD>ОК. Предположим экспортировали мы анонимные типы из сборки. А что делать в той сборке в которую они подключаются, если в ней так же используются такие же анонимные типы? Ведь будет же конфликт имен.
Если та сборка из которой мы их подключили известна в компайл тайме — будут задействованы те же анонимные типы. Если неизвестна — они не будут пересекаться.
Здравствуйте, Ziaw, Вы писали:
Z>Если та сборка из которой мы их подключили известна в компайл тайме — будут задействованы те же анонимные типы. Если неизвестна — они не будут пересекаться.
А если два анонимных типа будут экспортированы из двух разных сборок подключенных к третьей?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
VD>>А если два анонимных типа будут экспортированы из двух разных сборок подключенных к третьей?
Z>Тут надо будет допилить макрос чтобы выбрал только один из них. Или язык не позволит?
Логика не позволит.
Что делать если где-то внутри одной из сборок будет создан экземпляр типа который макрос отбросил?
Хотя это уже философский вопрос, потому как до этого дело не дойдет. Если они будут в одном пространстве имен (а это так и будет), то компиляция окончится с сообщением об ошибке "неоднозначность...".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Тут надо будет допилить макрос чтобы выбрал только один из них. Или язык не позволит?
VD>Логика не позволит.
VD>Что делать если где-то внутри одной из сборок будет создан экземпляр типа который макрос отбросил?
VD>Хотя это уже философский вопрос, потому как до этого дело не дойдет. Если они будут в одном пространстве имен (а это так и будет), то компиляция окончится с сообщением об ошибке "неоднозначность...".
Единственное разумное решение которое я на сегодня вижу — это:
1. Экспортируемые анонимные типы (т.е. реальные типы генерируемые для них) помещать в отдельные пространства имен. Например, соответствующие имени сборки из которой они экспортируются (или задаваемое в метаатрибуте).
2. Сборка использующая анонимные типы из нескольких других сборок должна генерировать свою копию аногимных типов используемых внутри нее и объявлять операторы неявного приведения типов для всех аналогичных импортированных типов.
Тогда для пользователя анонимные типы будут относительно прозрачными сущностями.
В случае если есть только одна сборка экспортер анонимных типов, можно использовать типы объявленные в ней.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Тут надо будет допилить макрос чтобы выбрал только один из них. Или язык не позволит?
VD>Логика не позволит.
VD>Что делать если где-то внутри одной из сборок будет создан экземпляр типа который макрос отбросил?
В каждой сборке будет экземпляр того типа который был определен при ее компиляции.
VD>Хотя это уже философский вопрос, потому как до этого дело не дойдет. Если они будут в одном пространстве имен (а это так и будет), то компиляция окончится с сообщением об ошибке "неоднозначность...".
А ты попробуй. Если указать имя руками ошибки не будет, компилятор выберет один из типов и выдаст предупреждение. А макрос должен позволить явно указать нужный тип, а не только имя класса.
Передача анонимных типов между границами сборок вещь очень неоднозначная, для работы с которой надо точно понимать принципы генерации этих типов и ограничения. Закладываясь на нее архитектурно надо рассматривать все возможные проблемы и вводить некие ограничения (например лишь одну сборку на проект с public типами).
Здравствуйте, Ziaw, Вы писали:
Z>Передача анонимных типов между границами сборок вещь очень неоднозначная, для работы с которой надо точно понимать принципы
генерации этих типов и ограничения. Закладываясь на нее архитектурно надо рассматривать все возможные проблемы и вводить некие ограничения (например лишь одну сборку на проект с public типами).
То, что предложил Влад выше — вполне реально, ограничения на "один проект с публичными анонимами" не нужно.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, VladD2, Вы писали:
Z>>>Тут надо будет допилить макрос чтобы выбрал только один из них. Или язык не позволит?
VD>>Логика не позволит.
VD>>Что делать если где-то внутри одной из сборок будет создан экземпляр типа который макрос отбросил?
Z>В каждой сборке будет экземпляр того типа который был определен при ее компиляции.
Читай внимательно контекст. Ты сказал "допилить макрос чтобы выбрал только один из них". Ну, выбрал он один из них. А что делать с тем который он не выбрал? Значения этого типа мы уже получить не сможем? Это косяк в дизайне. Такие фичи лучше не иметь во все.
VD>>Хотя это уже философский вопрос, потому как до этого дело не дойдет. Если они будут в одном пространстве имен (а это так и будет), то компиляция окончится с сообщением об ошибке "неоднозначность...".
Z>А ты попробуй.
Зачем? Точнее зачем нужны подобные не конструктивные реплики?
Z>Если указать имя руками
Где и зачем?
Z>ошибки не будет, компилятор выберет один из типов и выдаст предупреждение.
Вообще ничего не понял. Если будут одноименные типы из разных сборок, то компилятор просто выдаст сообщение об ошибке. Если они имеют разные имена, то опять же по какому принципу они будут задаваться и как использоваться.
Z> А макрос должен позволить явно указать нужный тип, а не только имя класса.
Какой макрос? Какой тип? Анонимные типы на то и анонимные, чтобы не иметь имени.
Работа с ними должна быть прозрачной. Прикладной программист не должен заморачиваться.
Z>Передача анонимных типов между границами сборок вещь очень неоднозначная, для работы с которой надо точно понимать принципы генерации этих типов и ограничения. Закладываясь на нее архитектурно надо рассматривать все возможные проблемы и вводить некие ограничения (например лишь одну сборку на проект с public типами).
Вот с этого надо было начинать. Значит есть ограничения... Одна сборка на проект. И что делать, если проекты (сборки) создавались параллельно, требовали экспорта анонимных типов, но в последствии были использованы в из другого проекта (обе сборки)?
Это все косяки. Именно по этой причине в C# 3.0 доступ к анонимным типам ограничили одной сборкой.
Делать половинчатые решения — это плохо. Это почти всегда приводит к парадоксам (а значит проблемам).
В 4-ом фрэймворке вроде бы появились какие-то возможности по структурной эквивалентности типов. Возможно после перехода на него получится решить проблему еще более элегантно. Но пока хотя бы будет на уровне предвидения типов работать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Читай внимательно контекст. Ты сказал "допилить макрос чтобы выбрал только один из них". Ну, выбрал он один из них. А что делать с тем который он не выбрал? Значения этого типа мы уже получить не сможем? Это косяк в дизайне. Такие фичи лучше не иметь во все.
Почему не сможем? Сможем ничуть не хуже чем без пабликов вообще. Паблики не ухудшают ситуацию здесь.
Z>>А ты попробуй.
VD>Зачем? Точнее зачем нужны подобные не конструктивные реплики?
Z>>Если указать имя руками
VD>Где и зачем?
Z>>ошибки не будет, компилятор выберет один из типов и выдаст предупреждение.
VD>Вообще ничего не понял. Если будут одноименные типы из разных сборок, то компилятор просто выдаст сообщение об ошибке. Если они имеют разные имена, то опять же по какому принципу они будут задаваться и как использоваться.
Конструктивные реплики как раз для того, чтобы ты попробовал скомпилировать. Тогда не возникало бы "вообще ничего не понял". Текущее поведение компилятора именно таково: когда он встречает 2 класса с одинаковым именем в одном неймспейсе, но разных сборках он выдает предупреждение и выбирает один из них сам.
VD>Работа с ними должна быть прозрачной. Прикладной программист не должен заморачиваться.
Прикладной программист вообще не должен заморачиваться передачей анонимных типов между сборками (именно типов, объекты анонимного типа передаются прекрасно), это нештатная ситуация. Типа выковыривания приватного поля через рефлекшн, только гораздо менее штатная и на метауровне.
VD>Вот с этого надо было начинать. Значит есть ограничения... Одна сборка на проект. И что делать, если проекты (сборки) создавались параллельно, требовали экспорта анонимных типов, но в последствии были использованы в из другого проекта (обе сборки)?
VD>Это все косяки. Именно по этой причине в C# 3.0 доступ к анонимным типам ограничили одной сборкой.
VD>Делать половинчатые решения — это плохо. Это почти всегда приводит к парадоксам (а значит проблемам).
VD>Рядом
Там те же самые парадоксы. Что делать когда эти сборки разрабатывались параллельно, но не известны на этапе компиляции другого проекта?
VD>В 4-ом фрэймворке вроде бы появились какие-то возможности по структурной эквивалентности типов. Возможно после перехода на него получится решить проблему еще более элегантно. Но пока хотя бы будет на уровне предвидения типов работать.
Я бы вообще считал это недокументированной возможностью, которую лучше не использовать.
Здравствуйте, Ziaw, Вы писали:
Z>Конструктивные реплики как раз для того, чтобы ты попробовал скомпилировать. Тогда не возникало бы "вообще ничего не понял". Текущее поведение компилятора именно таково: когда он встречает 2 класса с одинаковым именем в одном неймспейсе, но разных сборках он выдает предупреждение и выбирает один из них сам.
Мне кажется ты чего-то путаешь. Что за предупреждение (точный текст)?
Компилятор и в более простых случаях должен сообщать об ошибках. А это чиста неоднозначность. Возможно это ошибка в компиляторе.
VD>>Работа с ними должна быть прозрачной. Прикладной программист не должен заморачиваться.
Z>Прикладной программист вообще не должен заморачиваться передачей анонимных типов между сборками (именно типов, объекты анонимного типа передаются прекрасно), это нештатная ситуация. Типа выковыривания приватного поля через рефлекшн, только гораздо менее штатная и на метауровне.
Ну, так ты же этим занимаешься. А ты ведь не разработчик макросов или компилятора.
VD>>Рядом
я предложил выход. Можно рассмотреть его.
Z>Там те же самые парадоксы. Что делать когда эти сборки разрабатывались параллельно, но не известны на этапе компиляции другого проекта?
Что значит не известны на этапе компиляции? Компилятор и макросы занимаются исключительно тем что известно на стадии компиляции. Рефлексия их не трогает. А если сборки подключены явно, то макросу не составит труда создать операторы приведения типов и обеспечить прозрачное использование.
VD>>В 4-ом фрэймворке вроде бы появились какие-то возможности по структурной эквивалентности типов. Возможно после перехода на него получится решить проблему еще более элегантно. Но пока хотя бы будет на уровне предвидения типов работать.
Z>Я бы вообще считал это недокументированной возможностью, которую лучше не использовать.
Тогда не надо ее использовать. Но ты же ведь хочешь ее использовать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Конструктивные реплики как раз для того, чтобы ты попробовал скомпилировать. Тогда не возникало бы "вообще ничего не понял". Текущее поведение компилятора именно таково: когда он встречает 2 класса с одинаковым именем в одном неймспейсе, но разных сборках он выдает предупреждение и выбирает один из них сам.
VD>Мне кажется ты чего-то путаешь. Что за предупреждение (точный текст)? VD>Компилятор и в более простых случаях должен сообщать об ошибках. А это чиста неоднозначность. Возможно это ошибка в компиляторе.
Warning: using type '[ClassLibrary2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]ClassLibrary1.Class1' that was defined in more than one assembly: '[ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]ClassLibrary1.Class1' (the first version was used)
Для подавления такого ворнинга и была идея в макросе new генерировать явную ссылку на тип уже имеющийся в одной из сборок, а не просто по имени (я не в курсе, есть ли такая возможность вообще).
VD>Ну, так ты же этим занимаешься. А ты ведь не разработчик макросов или компилятора. VD>Тогда не надо ее использовать. Но ты же ведь хочешь ее использовать?
Вобщем да. Хотя я могу обойтись и своей версией new.
Здравствуйте, VladD2, Вы писали:
VD>Единственное разумное решение которое я на сегодня вижу — это: VD>1. Экспортируемые анонимные типы (т.е. реальные типы генерируемые для них) помещать в отдельные пространства имен. Например, соответствующие имени сборки из которой они экспортируются (или задаваемое в метаатрибуте).
VD>2. Сборка использующая анонимные типы из нескольких других сборок должна генерировать свою копию аногимных типов используемых внутри нее и объявлять операторы неявного приведения типов для всех аналогичных импортированных типов.
VD>Тогда для пользователя анонимные типы будут относительно прозрачными сущностями.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, VladD2, Вы писали:
VD>>Единственное разумное решение которое я на сегодня вижу — это: VD>>1. Экспортируемые анонимные типы (т.е. реальные типы генерируемые для них) помещать в отдельные пространства имен. Например, соответствующие имени сборки из которой они экспортируются (или задаваемое в метаатрибуте).
VD>>2. Сборка использующая анонимные типы из нескольких других сборок должна генерировать свою копию аногимных типов используемых внутри нее и объявлять операторы неявного приведения типов для всех аналогичных импортированных типов.
VD>>Тогда для пользователя анонимные типы будут относительно прозрачными сущностями.
H>Функционал добавил в r8912.
Со вторым пунктом вроде понятно — тесты наглядные, а по какому принципу работает именование и выбор неймспейсов для анонимных типов?
Здравствуйте, seregaa, Вы писали:
H>>Функционал добавил в r8912.
S>Со вторым пунктом вроде понятно — тесты наглядные, а по какому принципу работает именование и выбор неймспейсов для анонимных типов?
Анонимные классы складываются в синтетический нэймспейс <>_N_AnonymousClasses, в котором и происходит их поиск (если есть публичные).
"Уникальность" имени достигается простейшим хэшем от текущего времени.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>"Уникальность" имени достигается простейшим хэшем от текущего времени.
VD>Не лучше ли использовать имя сборки? А то время как раз может совпасть. Причем это будет уже когда все забудут о твоем решении.
Там не время, там произведение тиков начала компиляции и текущего значения, при том совпасть должны еще и сигнатуры анонимных типов. Имхо вполне допустимый хэш. Конечно можно и улучишть — сделать аккумулятор этих произведений.
