У меня есть несколько предложений по архитектуре. Не знаю, насколько это сейчас актуально, я вижу народ уже начал что-то кодить...
Мне кажется, что работу над чтением метаданных можно начать в рамках N1 методом глубокого рефакторинга.
1) Сейчас в N1 проблема в том, что везде используется Reflection, в том числе в публичных интерфейсах есть ссылки на SR. Первым этапом можно вынести всю работу рефлекшеном в отдельный модуль с абстрактным интефесом, т.е. абстрагировать работу с метаданными.
2) После первого этапа у нас будет минимальный абстактный интерфейс для чтения метаданных и будет одна имплементация — через Reflection.
3) Затем можно параллельно делать имплементацию абстактного интерфейса для различных бэкендов.
4) И параллельно с реализацией под различные бэкенды можно писать уже в рамках N2 реализацию более высокоуровнего и специфического для Nemerle интерфейса поверх существующего абстрактного интерфейса.
5) Абстрактный интерфейс должен быть а) минимальным, б) простым, с) CLS-compliant чтобы можно было делать реализацию на любом языке. Это важно, так как интерфейс AbsIL, например, заточен под F#, соответствнно и реализацию абстактного интерфеса поверх AbsIL проще всего писать на F#.
Плюсы данного подхода:
— Не дожидаясь релиза N2 получаем новые возможности и/или ускорение работы уже в N1
— Упрощается тестирование нового кода — можно просто сравнивать вывод компилятора с эталонным
— Заметно упрощается реализация под различне бэкенды, т.к. абстрагирование от бэкенда происходит на более низком уровне и интерфейс будет более простой.
— Соблюдается прницип Separation Of Concerns: реализация специфических для Nemerle требований никак не зависит от бэкенда.
Сорри, хотел запостить сообщение в существующую тему, вместо этого по ошибке создал новую тему. Просьба к модераторам: если есть возможность — прибейте тему и перенесите сообщение в существующую.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, #AVM, Вы писали:
AVM>>Мне кажется, что работу над чтением метаданных можно начать в рамках N1 методом глубокого рефакторинга.
H>В этом и проблема, такой рефакторинг уже пытались сделать, но в существующем коде крайне высока связность с SRE.
В таком случае, возможно не стоит отделять задачу чтения метаданных от задачи генерации кода. Если эти задачи так тесно связаны между собой.
Т.е. абстракция от бэкенда толжна включать в себя не только чтение метаданных, но сразу и кодогенерацию.
Здравствуйте, #AVM, Вы писали:
AVM>В таком случае, возможно не стоит отделять задачу чтения метаданных от задачи генерации кода. Если эти задачи так тесно связаны между собой.
Это разные задачи. Метаданные могут приезжать вообще из другого проекта, открытого в IDE (который еще не компилировался).
А тесно связаны они в компиляторе потому как никто изначально не задумывался об их разделении.
Здравствуйте, hardcase, Вы писали:
AVM>>Мне кажется, что работу над чтением метаданных можно начать в рамках N1 методом глубокого рефакторинга.
H>В этом и проблема, такой рефакторинг уже пытались сделать, но в существующем коде крайне высока связность с SRE.
Твое предложение можно упростить не потеряв смысла — "в существующем коде крайне высока связность".
Связи с SRE — это уже следствие. К сожалению о том, что такое инкапсуляция поляки похоже так и не узнали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, #AVM, Вы писали:
AVM>У меня есть несколько предложений по архитектуре. Не знаю, насколько это сейчас актуально, я вижу народ уже начал что-то кодить...
Как бы это по проще объяснить. Не стоит думать что другие глупее тебя. Все твои мысли — это мысли Камитана Очевидность.
Если бы все было так просто, то все давно сделали бы "по правильному".
Проблема только в том, что сделать это все не так просто. Как правильно заметил Хардкейс в коде компилятора огромная связанность. Причем не только с SRE, но и вообще. Повсеместно нарушаются принципы инкапсуляции и вообще хорошего тона и здравого смысла. В добавок сборка компилятора по минимуму занимает 2.5 минуты. Посему даже мелкие правки даются с большим трудом. А уж большие просто не проходят.
Одна из задач Н2 — переписывание кода начисто (т.е. без грязи). Собственно работа по написанию провайдера для CCI уже близка к финалу. За другие интерфейсы никто не взялся, но абстракции мы заложили, то что в принципе ни что не помешает этого сделать.
Ну, а делать какой-то универсальный АПИ для работы с метаданными мы не собираемся. Это не наша задача. В прочем, если кому-то захочется воспользоваться нашим механизмом, то мы конечно против не будем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Одна из задач Н2 — переписывание кода начисто (т.е. без грязи). Собственно работа по написанию провайдера для CCI уже близка к финалу. За другие интерфейсы никто не взялся, но абстракции мы заложили, то что в принципе ни что не помешает этого сделать.
VD>Ну, а делать какой-то универсальный АПИ для работы с метаданными мы не собираемся. Это не наша задача. В прочем, если кому-то захочется воспользоваться нашим механизмом, то мы конечно против не будем.
Исходя из твоих слов ранее, в обязанность провайдера входит в том числе чтение метаданных в отдельном потоке. Вполне возможно, что нарисуются со времени и другие требования, специфические для Nemerle. В случае, если по факту у нас так и будет только один бэкенд — это в общем не критично.
Если же планируется делать провайдеры и для других бэкендов — то лучше бы обязанности не связанные непосредственно с чтением метаданных вынести за пределы провайдера. Чтобы реализация этих дополнительных требований не зависела от выбранного бэкенда и не надо было дублировать код в каждом провайдере.
Здравствуйте, #AVM, Вы писали:
AVM>Исходя из твоих слов ранее, в обязанность провайдера входит в том числе чтение метаданных в отдельном потоке.
Это не обязанность, а требование. Провайдер должен писаться в расчете на то, что метаданные отдельных сборок будут читаться параллельно (в разных потока). Соответственно надо писать код так чтобы это было возможно, и тестировать полученный код в многопоточном окружении.
AVM>Вполне возможно, что нарисуются со времени и другие требования, специфические для Nemerle. В случае, если по факту у нас так и будет только один бэкенд — это в общем не критично.
Многопоточность не является чем-то специфичным для немерла. Вот публичный интерфейс, да. И нам это по фигу, так как задача у нас сделать бэкэнд, а не написать универсальный код с помощью которого можно решать абстрактные задачи.
AVM>Если же планируется делать провайдеры и для других бэкендов — то лучше бы обязанности не связанные непосредственно с чтением метаданных вынести за пределы провайдера. Чтобы реализация этих дополнительных требований не зависела от выбранного бэкенда и не надо было дублировать код в каждом провайдере.
Еще раз повторюсь, не надо выступать в роли Комитана Очевидности. Бэкэн конечно же занимается только своими обязанностями.
Корочое, тут нечего обсуждать. Бэкэнд для CCI готов где-то процентов на 80-90.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Это не обязанность, а требование. Провайдер должен писаться в расчете на то, что метаданные отдельных сборок будут читаться параллельно (в разных потока). Соответственно надо писать код так чтобы это было возможно, и тестировать полученный код в многопоточном окружении.
Ок, значит я просто неправильно тебя понял. На этом обсуждение можно закончить действительно, тем более что CCI провайдер уже почти готов.
