Здравствуйте, VladD2, Вы писали:
VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
VD>Давно хотелось запретить это дело.
VD>Может быть перед тем как выпускать бэту ввести такое ограничение?
VD>Естественно, что в интеграции нужно будет сделать официальный путь для подключения макросных сборок. Я уже работают над этим.
Надо-надо!
А возможно это оформить как "галочку" в свойствах ссылки?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, hardcase, Вы писали:
H>А возможно это оформить как "галочку" в свойствах ссылки?
Я хочу сделать по-другому.
Я добавлю еще один виртуальный каталог аналогичный каталогу References, но носящий имя MacroReferences и имеющий чуть другую иконку. В нем будут находиться только ссылки на макро-сборки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Запретить подключение macro-сборок как обычных сборок?
Здравствуйте, VladD2, Вы писали: VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme?
Re[2]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, VladD2, Вы писали: VD>>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям. MC>Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme?
Это изначально было так, опция подключения макро-сборок просто не была выведена на интерфейс, но она есть: параметр компилятора -m или -macros, если не ошибаюсь.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, Mr.Cat, Вы писали:
MC>Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme?
В нем по другому просто не было никогда.
Здесь же речь не о стадиях, а о том, чтобы разделить подключение библиотек и макро-сборок. Сейчас если подключаешь библиотеку и в ней есть макросы, то макросы автоматически считываются и становятся доступны для использования.
Это чревато тем, что люди будут халтурить или просто путаться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, VladD2, Вы писали: MC>>Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme? VD>В нем по другому просто не было никогда.
Ага, т.е. и функцию в сборке нельзя вызывать (именно вызывать, не раскрываться в нее) в макросе той же сборки?
Re[4]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, Mr.Cat, Вы писали:
MC>Ага, т.е. и функцию в сборке нельзя вызывать (именно вызывать, не раскрываться в нее) в макросе той же сборки?
По пунктам...
Основные понятия:
1. Проект — набор исходников которые компилируются компилятором в сборку (упрощенно — исполняемый модуль dll или exe).
2. Ссылка на сборку (Assembly reference) — ссылка на другую сборку (обычно на dll) содержащую библиотечный код. Нужна для того чтобы создавать и использовать типы и функции объявленные в другой сборке.
3. Макро-сборка — сборка в которой реализован макрос. Загружается компилятором с целью использования объявленных в ней макросов для преобразования кода компилируемого проекта.
Так вот, так как и сборка на которую ссылается проект и макро-сборка — это по сути просто dll, то потенциально макросы могут быть в любой сборке. Однако для компиляции простые сборки загружаются не для выполнения, а только для считывания мета-информации. Макро-сборки же загружаются в процесс компилятора на выполнение. Их мета-информация не нужна для конечной программы. Данный вид сборки нужен только для запуска макросов в ней находящихся.
На сегодня, если обычная сборка (т.е. Assembly reference) содержит в себе макросы, макросы автоматически считываются и становятся доступны для использования. Это может привести к нежелательным последствиям:
1. Макрос может быть использован нечаянно.
2. Это может приводить к плохому дизайну приложения — смешению макро-кода и кода используемого в конченом приложении, так как есть соблазн схалтурить и разместить код в одной сборке, а не разделять на две.
Так вот я и предлагаю запретить считывание макросов из обычных сборок (Assembly reference) и тем самым заставить людей явно указывать маро-сборки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Запретить подключение macro-сборок как обычных сборок?
Здравствуйте, VladD2, Вы писали: VD>Так вот, так как и сборка на которую ссылается проект и макро-сборка — это по сути просто dll, то потенциально макросы могут быть в любой сборке. Однако для компиляции простые сборки загружаются не для выполнения, а только для считывания мета-информации. Макро-сборки же загружаются в процесс компилятора на выполнение. Их мета-информация не нужна для конечной программы. Данный вид сборки нужен только для запуска макросов в ней находящихся.
Ага, т.е в немерле 2 разделения:
1. Ссылки на сборки — для компиляции и для обычные дотнетные референсы для рантайма.
2. Сборки — для подключения только на время компиляции и для подключения как угодно.
Я правильно понимаю?
Re[3]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, Mr.Cat, Вы писали:
MC>Ага, т.е в немерле 2 разделения: MC>1. Ссылки на сборки — для компиляции и для обычные дотнетные референсы для рантайма. MC>2. Сборки — для подключения только на время компиляции и для подключения как угодно. MC>Я правильно понимаю?
Что-то как-то запутано у тебя получилось.
Есть просто сборки и макро-сборки. Первый нужны для подключения к конечным приложениям в качестве обычных библиотек, вторые выступают в роли плагинов к компилятору и подключаются к проекту для того чтобы использовать содержащиеся в нем макросы во время компиляции проекта.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, VladD2, Вы писали:
VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
А если пользователь просто подключить одну и ту же сборку два раза — как простую и как макросную? Может фильтровать сборки, доступные для подключения, по специальному атрибуту или как было предложено — по наименованию?
Re[2]: Запретить подключение macro-сборок как обычных сборок
От:
Аноним
Дата:
12.02.10 09:24
Оценка:
Здравствуйте, seregaa, Вы писали:
S>А если пользователь просто подключить одну и ту же сборку два раза — как простую и как макросную? Может фильтровать сборки, доступные для подключения, по специальному атрибуту или как было предложено — по наименованию?
Пусть и подключает два раза
Мне идея с разделением нравится, и я давно думал, какие же это проблемы в компиляторе заставляют нас пользоваться -r вместо -m в интеграции.
Re[3]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, Аноним, Вы писали:
А>Пусть и подключает два раза
А>Мне идея с разделением нравится, и я давно думал, какие же это проблемы в компиляторе заставляют нас пользоваться -r вместо -m в интеграции.
А не будет проблем с выявлением зависимостей при билде солюшена, если сборка была подключена не как reference?
Re[4]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Аноним, Вы писали:
А>>Пусть и подключает два раза
А>>Мне идея с разделением нравится, и я давно думал, какие же это проблемы в компиляторе заставляют нас пользоваться -r вместо -m в интеграции.
L>А не будет проблем с выявлением зависимостей при билде солюшена, если сборка была подключена не как reference?
Очевидно интеграция должна просто игнорировать -m подключение, если есть аналогичное, но -r.
У результирующей сборки зависимости будут только от -r сборок. -m нужны исключительно для выполнения компиляции.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: Запретить подключение macro-сборок как обычных сборок
Здравствуйте, hardcase, Вы писали:
H>Очевидно интеграция должна просто игнорировать -m подключение, если есть аналогичное, но -r. H>У результирующей сборки зависимости будут только от -r сборок. -m нужны исключительно для выполнения компиляции.
Все не так просто. Порядок компиляции должен определяться и макро-ссылками. Ведь если макро-сборка не скомпилировалась, то применять ее глупо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Запретить подключение macro-сборок как обычных сборок?
Здравствуйте, VladD2, Вы писали:
VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям. VD>Давно хотелось запретить это дело. VD>Может быть перед тем как выпускать бэту ввести такое ограничение? VD>Естественно, что в интеграции нужно будет сделать официальный путь для подключения макросных сборок. Я уже работают над этим.
Абсолютно согласен. Тогда можно будет сделать самособирающуюся сборку с макросами — добавить ссылку на копию самой себя, как это неявно сделано с Nemerle.Macros.dll.
Таким же путём можно будет сделать чтобы сборка с макросами Xxx.Macros.dll ссылалась (-ref) на ../boot/Xxx.dll (копия), которая в свою очередь ссылается (-macro) на Xxx.Macros.dll.
Т.е. разрешается конфликт циклической зависимости.
Сильно не хватает поддержки такой фишки intelly sense'ом.
Нужно для того что бы компоновать свои наработки макросов.