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

Давно хотелось запретить это дело.

Может быть перед тем как выпускать бэту ввести такое ограничение?

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

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

VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.

VD>Давно хотелось запретить это дело.

VD>Может быть перед тем как выпускать бэту ввести такое ограничение?

VD>Естественно, что в интеграции нужно будет сделать официальный путь для подключения макросных сборок. Я уже работают над этим.


Надо-надо!
А возможно это оформить как "галочку" в свойствах ссылки?

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

H>А возможно это оформить как "галочку" в свойствах ссылки?

Я хочу сделать по-другому.

Я добавлю еще один виртуальный каталог аналогичный каталогу References, но носящий имя MacroReferences и имеющий чуть другую иконку. В нем будут находиться только ссылки на макро-сборки.

Здравствуйте, VladD2, Вы писали:
VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme?

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

MC>Здравствуйте, VladD2, Вы писали:
VD>>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
MC>Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme?

Это изначально было так, опция подключения макро-сборок просто не была выведена на интерфейс, но она есть: параметр компилятора -m или -macros, если не ошибаюсь.

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

MC>Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme?

В нем по другому просто не было никогда.

Здесь же речь не о стадиях, а о том, чтобы разделить подключение библиотек и макро-сборок. Сейчас если подключаешь библиотеку и в ней есть макросы, то макросы автоматически считываются и становятся доступны для использования.

Это чревато тем, что люди будут халтурить или просто путаться.

Здравствуйте, VladD2, Вы писали:
MC>>Nemerle двигается в сторону явного разделения стадий компиляции, а-ля r6rs или plt scheme?
VD>В нем по другому просто не было никогда.
Ага, т.е. и функцию в сборке нельзя вызывать (именно вызывать, не раскрываться в нее) в макросе той же сборки?

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

MC>Ага, т.е. и функцию в сборке нельзя вызывать (именно вызывать, не раскрываться в нее) в макросе той же сборки?

По пунктам...

Основные понятия:
1. Проект — набор исходников которые компилируются компилятором в сборку (упрощенно — исполняемый модуль dll или exe).
2. Ссылка на сборку (Assembly reference) — ссылка на другую сборку (обычно на dll) содержащую библиотечный код. Нужна для того чтобы создавать и использовать типы и функции объявленные в другой сборке.
3. Макро-сборка — сборка в которой реализован макрос. Загружается компилятором с целью использования объявленных в ней макросов для преобразования кода компилируемого проекта.

Так вот, так как и сборка на которую ссылается проект и макро-сборка — это по сути просто dll, то потенциально макросы могут быть в любой сборке. Однако для компиляции простые сборки загружаются не для выполнения, а только для считывания мета-информации. Макро-сборки же загружаются в процесс компилятора на выполнение. Их мета-информация не нужна для конечной программы. Данный вид сборки нужен только для запуска макросов в ней находящихся.

На сегодня, если обычная сборка (т.е. Assembly reference) содержит в себе макросы, макросы автоматически считываются и становятся доступны для использования. Это может привести к нежелательным последствиям:
1. Макрос может быть использован нечаянно.
2. Это может приводить к плохому дизайну приложения — смешению макро-кода и кода используемого в конченом приложении, так как есть соблазн схалтурить и разместить код в одной сборке, а не разделять на две.

Так вот я и предлагаю запретить считывание макросов из обычных сборок (Assembly reference) и тем самым заставить людей явно указывать маро-сборки.

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

Может им для пущего разделения стоит добавить расширение Something.macros.dll?

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

D>Может им для пущего разделения стоит добавить расширение Something.macros.dll?

Ну, как конвенция по наименованию это может быть и не плохо.

С точки зрения реализации и компилятор, и интеграция и так их по содержимому отличит.

Здравствуйте, VladD2, Вы писали:
VD>Так вот, так как и сборка на которую ссылается проект и макро-сборка — это по сути просто dll, то потенциально макросы могут быть в любой сборке. Однако для компиляции простые сборки загружаются не для выполнения, а только для считывания мета-информации. Макро-сборки же загружаются в процесс компилятора на выполнение. Их мета-информация не нужна для конечной программы. Данный вид сборки нужен только для запуска макросов в ней находящихся.
Ага, т.е в немерле 2 разделения:
1. Ссылки на сборки — для компиляции и для обычные дотнетные референсы для рантайма.
2. Сборки — для подключения только на время компиляции и для подключения как угодно.
Я правильно понимаю?

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

VD>С точки зрения реализации и компилятор, и интеграция и так их по содержимому отличит.

Можно было бы в диалоге добавления макросов, фильровать dll'ки

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

MC>Ага, т.е в немерле 2 разделения:
MC>1. Ссылки на сборки — для компиляции и для обычные дотнетные референсы для рантайма.
MC>2. Сборки — для подключения только на время компиляции и для подключения как угодно.
MC>Я правильно понимаю?

Что-то как-то запутано у тебя получилось.

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

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

D>Можно было бы в диалоге добавления макросов, фильровать dll'ки

На сборки не содержащие макросов и так будет выдаваться предупреждение.

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

VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
А если пользователь просто подключить одну и ту же сборку два раза — как простую и как макросную? Может фильтровать сборки, доступные для подключения, по специальному атрибуту или как было предложено — по наименованию?

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

S>А если пользователь просто подключить одну и ту же сборку два раза — как простую и как макросную? Может фильтровать сборки, доступные для подключения, по специальному атрибуту или как было предложено — по наименованию?

Пусть и подключает два раза

Мне идея с разделением нравится, и я давно думал, какие же это проблемы в компиляторе заставляют нас пользоваться -r вместо -m в интеграции.

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

А>Пусть и подключает два раза

А>Мне идея с разделением нравится, и я давно думал, какие же это проблемы в компиляторе заставляют нас пользоваться -r вместо -m в интеграции.

А не будет проблем с выявлением зависимостей при билде солюшена, если сборка была подключена не как reference?

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

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

А>>Пусть и подключает два раза

А>>Мне идея с разделением нравится, и я давно думал, какие же это проблемы в компиляторе заставляют нас пользоваться -r вместо -m в интеграции.

L>А не будет проблем с выявлением зависимостей при билде солюшена, если сборка была подключена не как reference?


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

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

H>Очевидно интеграция должна просто игнорировать -m подключение, если есть аналогичное, но -r.
H>У результирующей сборки зависимости будут только от -r сборок. -m нужны исключительно для выполнения компиляции.

Все не так просто. Порядок компиляции должен определяться и макро-ссылками. Ведь если макро-сборка не скомпилировалась, то применять ее глупо.

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

VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
VD>Давно хотелось запретить это дело.
VD>Может быть перед тем как выпускать бэту ввести такое ограничение?
VD>Естественно, что в интеграции нужно будет сделать официальный путь для подключения макросных сборок. Я уже работают над этим.

Абсолютно согласен. Тогда можно будет сделать самособирающуюся сборку с макросами — добавить ссылку на копию самой себя, как это неявно сделано с Nemerle.Macros.dll.
Таким же путём можно будет сделать чтобы сборка с макросами Xxx.Macros.dll ссылалась (-ref) на ../boot/Xxx.dll (копия), которая в свою очередь ссылается (-macro) на Xxx.Macros.dll.
Т.е. разрешается конфликт циклической зависимости.

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