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

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

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

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

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

Можно добавить такой фильтр. Это (думаю) не сложно.

Можно его даже сделать фильтром по умолчанию. Не знаю только не будет ли это перебором.

Вот что точно надо сделать, так это переименовать шаблон маро-сборки так чтобы у него по умолчанию было это расширение.

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

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

Хороший вопрос! Надо будет его обязательно отработать. Конечно ссылка на макро-сборку — это зависимость которая должна приводить к перекомпиляции проекта.

Надо будет сделать так, чтобы элементы (Items) MacroReference и MacroProjectReference входили в зависимости. И так же обеспечить проверку циркулярных ссылок.

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

P>Абсолютно согласен. Тогда можно будет сделать самособирающуюся сборку с макросами — добавить ссылку на копию самой себя, как это неявно сделано с Nemerle.Macros.dll.

Не все так просто. Делать рекурсивную ссылку не стоит. Это чревато множеством проблем (главная из который — постоянная перекомпиляция проекта).

В подобных случаях нужно поступать так же как сделано в компиляторе. Должен быть некий Boot — набор сборок с использованием которых собирается проект. Когда в сборку вносится некоторое изменение которое требуется для дальнейшего развития проекта, то Boot обновляется и помещается в систему контроля версий. Иначе можно легко оказаться в положении когда продут невозможно собрать самим собой.

Так что подключать сборку к самой себе напрямую ни в коем случае нельзя!

P>Таким же путём можно будет сделать чтобы сборка с макросами Xxx.Macros.dll ссылалась (-ref) на ../boot/Xxx.dll (копия), которая в свою очередь ссылается (-macro) на Xxx.Macros.dll.

Можно. Но именно что на копии.

P>Т.е. разрешается конфликт циклической зависимости.

Нет. Здесь не будет цикла. Собираемые сборки будут зависеть от Boot-версий.

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

Папку Macro References я уже почти сделал. Думаю за выходные я ее доделаю, оттестирую и она будет официально доступна.

Сейчас же стоит вопрос — "Нужно ли вводить в компилятор запрет на чтение макросов из обычных сборок (т.е. подключенных по -ref, а не по -m)?".

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

VD>Сейчас же стоит вопрос — "Нужно ли вводить в компилятор запрет на чтение макросов из обычных сборок (т.е. подключенных по -ref, а не по -m)?".

думаю что не стоит.
это с одной стороны не криминально
с другой, лучше выдавать ворнинг, что мол, нехороший стиль.

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

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

VD>>Сейчас же стоит вопрос — "Нужно ли вводить в компилятор запрет на чтение макросов из обычных сборок (т.е. подключенных по -ref, а не по -m)?".

P>с другой, лучше выдавать ворнинг, что мол, нехороший стиль.

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

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

VD>Сейчас же стоит вопрос — "Нужно ли вводить в компилятор запрет на чтение макросов из обычных сборок (т.е. подключенных по -ref, а не по -m)?".

Конечно, стоит, иначе какой смысл конечному пользователю использовать Macro References, если и с обычными References все работает.

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

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

VD>>Сейчас же стоит вопрос — "Нужно ли вводить в компилятор запрет на чтение макросов из обычных сборок (т.е. подключенных по -ref, а не по -m)?".

L>Конечно, стоит, иначе какой смысл конечному пользователю использовать Macro References, если и с обычными References все работает.

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

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

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

VD>>>Сейчас же стоит вопрос — "Нужно ли вводить в компилятор запрет на чтение макросов из обычных сборок (т.е. подключенных по -ref, а не по -m)?".

L>>Конечно, стоит, иначе какой смысл конечному пользователю использовать Macro References, если и с обычными References все работает.

P>не согласен. любой запрет ограничивает варианты использования.

собственно, цель любого запрета — ограничить определенные варианты использования. если это полезные запреты, то они ограничивают вредные варианты использования.

P>которые в данном случае не противоречат концепции.

Они противоречат цели, которая была сформулирована в первом посте.

P>например такой вариант:
P>в макросной сборке содержится модуль-хелпер.
P>сейчас, можно сделать другую макросную сборку, которая использует этот же класс.

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

P>это выдуманный пример, но может сложится так, что и этот сценарий понадобится для взаимодействия с чужим кодом.

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

отключаемы ворнинг — отличный повод на него забить.

Здравствуйте, VladD2, Вы писали:
VD>Смешение макрос-сборок и обычных библиотечных сборок (экспортирующих типы) — это явный путь к кривому дизайну и паразитным зависимостям.
VD>Давно хотелось запретить это дело.
Use-case:
1. Пусть макросы генерируют код, использующий другую библиотеку. Сейчас достаточно макросборке зависеть от неё, а приложению от макросборки. Заставлять подключать в зависимости сборку вручную или же втихую из макроса кажется злом.

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

VD>Может быть перед тем как выпускать бэту ввести такое ограничение?
Чтобы какую-то "некрасивую" функциональность запретить, надо как минимум понять, что в реальной жизни
желание схалтурить с её использованием во-первых возникает, во-вторых ведёт к плохому решению и в-третьих есть другой правильный путь, не сложнее на порядок, примерно такой же по удобству и в меру понятный/интуитивный.
Все эти пункты выполняются на практике?

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

ИД>2. То же самое, но вспомогательные классы лежат в макросборке, т.к. специфичны для неё — нет смысла отделять, и те же проблемы с подключением в случае разделения.

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

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

VD>>Может быть перед тем как выпускать бэту ввести такое ограничение?
ИД>Чтобы какую-то "некрасивую" функциональность запретить, надо как минимум понять, что в реальной жизни
ИД>желание схалтурить с её использованием во-первых возникает, во-вторых ведёт к плохому решению и в-третьих есть другой правильный путь, не сложнее на порядок, примерно такой же по удобству и в меру понятный/интуитивный.
ИД>Все эти пункты выполняются на практике?

На практике видна проблема. Сам грешным делом мешал макры и библиотеки, так что понимаю насколько это заманчиво.

Ну, а мысли эти появились после того как я начал думать о переходе на другие рантаймы (тот же дотнет 4.0) и о смене движка генерации MSIL-а. При этом вред смешения библиотек и макросов становится полностью очевидным. Смешанный код не переносим.

В принципе действительно можно ЗАПРЕТИТЬ и при необходимости создавать и -ref и -m на сборку.
Если кому надо, можно добавить опцию разрешения этого дела для обратной совместимости, но делать код не [ClsCompiliant].
В любом случае, при обнаружении в -ref сборке макросов, надо выводить ворнинг или хинт для тех кто не вкурсе дела.

Здравствуйте, VladD2, Вы писали:
VD>Ну, а мысли эти появились после того как я начал думать о переходе на другие рантаймы (тот же дотнет 4.0) и о смене движка генерации MSIL-а. При этом вред смешения библиотек и макросов становится полностью очевидным. Смешанный код не переносим.
Так понятнее, возможность убрать зависимость необходима, т.к. является blocker-ом.
— убрать зависимость и посмотреть, что будет хотя бы на проектах в репозитории
— добавить правильных предупреждений, возможно таких:
— — объявлен public класс при компиляции макросборки
— — объявлен макрос при обычной сборке
— — при подключении по ref макросборки — "макросы не подцепились"
— — при подключении макросборки с public классами — "классы не подцепились"
— где-то в доках и в ncc --help явно написать, что ref и m для разного
— проверить, что работает одновременное подключение по ref и m

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

ИД>Так понятнее, возможность убрать зависимость необходима, т.к. является blocker-ом.
ИД>- убрать зависимость и посмотреть, что будет хотя бы на проектах в репозитории
ИД>- добавить правильных предупреждений, возможно таких:
ИД>- — объявлен public класс при компиляции макросборки
ИД>- — объявлен макрос при обычной сборке
ИД>- — при подключении по ref макросборки — "макросы не подцепились"
ИД>- — при подключении макросборки с public классами — "классы не подцепились"
ИД>- где-то в доках и в ncc --help явно написать, что ref и m для разного
ИД>- проверить, что работает одновременное подключение по ref и m

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

Я сейчас склоняюсь к введению дополнительного ключа компиляции который введет режим совместимости со старым подходом и выдачу ошибок в противном случае. Возможно у ключа сделать два значения:
1. Позволяющее ссылаться на одну сборку через -m и -r.
2. Позволяющее считывать макры из -r (без передупреждений).

Ну, и в доках все это дело нужно описать (и в описании этого нового ключа).

Ключ можно назвать -allow-mixing-macro-and-lib-refs