Здравствуйте, VladD2, Вы писали:
VD>>>Завел соответствующий issues.
Поправил перевод, 4 пункт убрал — уж слишком специфичный.
VD>Поясню, что это значит на примере. Предположим у нас есть тип: VD>
VD>class A[T] { }
VD>
VD>и его наследник: VD>
VD>class B[X] : A[X] { }
VD>
VD>Если мы захотим получить тип A[X], то нам потребуется подставить...
Пример понял, но вот зачем нужно подставление метаридеру — х/з. Он же ведь просто читает данные о сборке? И если там дженерик тип, он просто читается как другие типы. Или я что-то не догоняю?
В этом проекте собраны базовые типы (в основном абстрактные и интерфейсы) описывающие систему типов немерла.
Тем кто занимается проектом чтения метаданных нужно реализовать наследника абстрактного типа NTypeInfo и приведенные там интерфейсы, так чтобы вся информация бралась из внешних сборок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Eter_, Вы писали:
_E_>* При реализации ExternalTypeInfo нужно брать реализацию из nemerle-1 и переделывать ее на новый лад, или писать по-новому?
Для начала нужно обновить свой клон, чтобы в него попали все изменения внесенные мной.
При реализации нужно постараться выполнить следующие условия:
1. Производить чтение метаданных каждой сборки в отдельном потоке (т.е. код должен быть по потоко-независимым, если это позволяет базовая библиотека).
2. При загрузке типов нужно сначала загружать только минимум информации: Имя, путь (пространство имен), количество параметров типов. Остальное нужно грузить по потребности. Особенно это важно при загрузке членов типов и вложенных типов, так как их может быть очень много.
3. Реализовать чтение атрибутов без загрузки сборок на выполнение.
Основная цель — ускорить первичную загрузку сборок. Так что в тестах имеет смысл замерять время чтения списка типов и формирование списка их имен.
ЗЫ
Желательно комитить промежуточные результаты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>Тогда вопрос: компилер будет переписываться полностью или у существующего немного подпилят код в сторону модульности?
Код будет переписан чуть менее чем полностью, конечно с оглядкой на существующую базу.
M>Я не вижу каких-то особых причин разделять практически единую сущность. Ну будет больше методов, лишнюю память же они не съедят! Да и extension methods вроде бы есть.
Вообще-то съедят. Они будут как минимум ссылаться на свой PExpr.
M>Как я понял, Влад уже попробовал CCI и его возможностей достаточно. На форуме уже бросаются заготовки классов для метаданных, хотя как и где они будут использоваться — вопрос (думаю, не только для меня? ).
Они используются в компиляторе фактически везде.
M>По сути, даже непонятно, что в компиляторе будет переписываться (см. вопрос выше).
С ходу:
1) Парсер
2) Кодогенератор
3) Механизмы типизации (за исключением алгоритма вывода типов)
Здравствуйте, matumba, Вы писали:
M>Пример понял, но вот зачем нужно подставление метаридеру — х/з. Он же ведь просто читает данные о сборке? И если там дженерик тип, он просто читается как другие типы. Или я что-то не догоняю?
Читается он как обычные типы, а вот чтобы использовать, его нужно параметризировать.
Первыми задачами (при разработке Nemerle 2) являются выбор нового бэкэнда для компилятора (в замен System.Reflection + System.Reflection.Emit), и реализация на его базе следующих классов (расположенных сейчас здесь):
1. LibraryManager — управляет загрузкой типов и макросов из внешних библиотек.
2. LibraryReference — описывает библиотеку (сборку).
3. ExternalTypeInfo и его наследников — описывают тип внутри компилятора.
4. ExternalMemberInfo и его наследников — описывают члены типов внутри компилятора.
В процессе работы нужно произвести рефакторинг указанных классов и полностью удалить из кода все ссылки на System.Reflection.*.
Собственно первая подзадача сформировать небольшую команду тех кому было бы интересно этим заниматься.
Почему-то (к сожалению) работа с метаданными и генерацией кода не очень популярна. Но она нужна не менее других (даже более, так как она нужна с самого начала). Кроме того это не хилый опыт который пригодится в жизни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Первыми задачами (при разработке Nemerle 2) являются выбор нового бэкэнда для компилятора (в замен System.Reflection + System.Reflection.Emit), и реализация на его базе следующих классов (расположенных сейчас здесь): VD>1. LibraryManager — управляет загрузкой типов и макросов из внешних библиотек. VD>2. LibraryReference — описывает библиотеку (сборку). VD>3. ExternalTypeInfo и его наследников — описывают тип внутри компилятора. VD>4. ExternalMemberInfo и его наследников — описывают члены типов внутри компилятора.
VD>В процессе работы нужно произвести рефакторинг указанных классов и полностью удалить из кода все ссылки на System.Reflection.*.
VD>Надо попытаться реализовать указанные классы на базе CCI Metadata и AbstractIL
из F#-а.
VD>PS
VD>Собственно первая подзадача сформировать небольшую команду тех кому было бы интересно этим заниматься.
VD>Почему-то (к сожалению) работа с метаданными и генерацией кода не очень популярна. Но она нужна не менее других (даже более, так как она нужна с самого начала). Кроме того это не хилый опыт который пригодится в жизни.
Вкратце описание типов которые нужно реализовать:
TypeInfo — описвает базовый абстрактный тип представляющий описание типа в компиляторе. TypeInfo описывает невоплощенный тип, т.е. тип без параметров типов. Его часто так же называют Type Constructor, от чего в компиляторе он частенько появляется в полях с именем tycon.
У этого класса есть ряд наследников в том числе наследники с префиксом "External": ExternalNemerleTypeInfo, ExternalPrimitiveTypeInfo, ExternalTypeInfo. Названия говорят сами за себя. ExternalTypeInfo — базовый тип описывающий загружаемые из сборок типы. ExternalNemerleTypeInfo — уточнеение предыдущего класса описывающие типы немерла (варианты и т.п.). ExternalPrimitiveTypeInfo — описывает примитивы и прибилднутые типы.
Задача этих типов получать общую информацию о типах:
* Имя типа.
* Пространство имен в котором объявлен тип.
* Полное имя (с пространством имен и внешними классами, если такие есть).
* Список параметров типов.
* Список членов (в отложенном режиме, чтобы на тратить время на разбор сигнатур которые могут никогда не понадобиться в программе, кроме приватных).
* Список вложенных типов.
* Список кастом-атрибутов. Тут все сложнее. Нужно уметь читать значение простых свойств атрибутов (прибилднутых типов). Как понимаешь читать их придется в режиме декомпиляции, так как сборку на исполнение поднимать нельзя (она может быть не того рантайма). CCI позволяет решить эту задачу на ура (я проверял).
* Модификаторы доступа (public/internal).
ExternalNemerleTypeInfo должен разбирать дополнительную информацию запакованную в виде спец.атрибутов. и воссоздавать информацию об определенных во внешних сборках вариантных типах и их вхождениях. Для рабора этой фигни есть тип TyCodec, который так же нужно переименовать, отрефакторить и приспособить к новым условиям.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
При реализации указанных классов нужно избавиться ото все типов из System.Reflection.
Так же нужно продумать как обеспечить инкапсуляцию типов из базовых API (CCI, AbsIL, ...).
Сейчас System.Reflection торчит из-зо всех дыр. В новой версии этих классов все детали базовых API должны быть скрыты. Однако эти детали обязательно потребуются при генерации сборок (IL-а и метаданных). По сему нужно продумать четкий интефейс между этими модулями при обеспечении инкапсуляции для остального кода.
Нам нужно выделить код отвечающий за загрузку типов в отдельную сборку. Все базовые типы при этом должны находиться в другой сборке, которая будет импортироваться сборкой чтения метаданных и другими сборками компилятора.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ребят, приветствую всех с окончанием года! У нас появились свободные деньки (до 5-го), хотел приобщить руки к делу.
Немного почитав про начинания с N2, создалось ощущение, что все уже всё знают. (я про кишки компилера, структуры, язык) А так как у меня практики особой не было, сижу как пенёк.
Но наверное это к лучшему, потому что у меня возник вполне резонный вопрос: а нет ли смысла начать с конца? Т.е. сначала определить язык, его типы, как они будут совмещаться с дотнетовскими, вообще подробно расписать _существенные_различия_ Немерли с дотентом, а потом уже придумывать утилитные классы, читалки метаатрибутов и т.п.
Вот уже Влад ввёл ExternalTypeInfo — почему экстернал? Разве в дотнете есть понятие "внешний тип"? Я бы сказал ровно наоборот: есть типы дотнета и какие-то специфичные для Немерли типы (варианты?), которые всё равно никакими "внешними" не будут — будут точно так же загружаться из сборок как string или Dictionary. Т.е. со всеми типами дотнетины мы будем работать одинаковым образом (ради чего дотнет и придумывался). Это правильное предположение?
Затем, хорошо бы как-то набросать схемок (вплоть до скана карандашного рисунка) того, из чего будет состоять компилятор — абстрактные "парсер", "лексер" мы все знаем, а нужна именно наглядная схема кто и что делает, какими данными обменивается, где хранит внутренние данные и вход/выход. Без общего понимания нет смысла бросаться кодить даже тем, кто понимает внутренности Немерли-1.
VD>Почему-то (к сожалению) работа с метаданными и генерацией кода не очень популярна.
Да пофиг, это ничуть не скучнее, чем хвостовая рекурсия — для такой нетривиальной задачи как компилер всегда найдутся интересные в реализации моменты. BLToolkit тоже в своём роде "стотыщный скучный маппер БД-объекты", а кода написано немало!
Вобщем, наверное все мою мысль поняли — для включения любого члена в работу, нужен фундамент — он же потом будет наглядной документацией.
На самом деле интересного там мало. Это слишком высокоуровневый АПИ. Как я понимаю он "гвоздями" пришит к семантике Шарпа и Васика. Так что нам он вряд ли подойдет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>Но наверное это к лучшему, потому что у меня возник вполне резонный вопрос: а нет ли смысла начать с конца? Т.е. сначала определить язык, его типы, как они будут совмещаться с дотнетовскими, вообще подробно расписать _существенные_различия_ Немерли с дотентом, а потом уже придумывать утилитные классы, читалки метаатрибутов и т.п.
Да в глобальном плане, насколько я понимаю, все удовлетворены немерле-1. Немерле-2 решает главные проблемы немерле-1, а это страшноватый код, использование System.Reflection и (дальше каждый пусть вставит свое).
M>Вот уже Влад ввёл ExternalTypeInfo — почему экстернал? Разве в дотнете есть понятие "внешний тип"?
В дотнете и нет, есть в наверное в любом достаточно продвинутом компиляторе. "Внешний тип" — тип, определенный не в сборке, которая компилируется в данный момент, вот и все
M>Затем, хорошо бы как-то набросать схемок (вплоть до скана карандашного рисунка) того, из чего будет состоять компилятор — абстрактные "парсер", "лексер" мы все знаем, а нужна именно наглядная схема кто и что делает, какими данными обменивается, где хранит внутренние данные и вход/выход. Без общего понимания нет смысла бросаться кодить даже тем, кто понимает внутренности Немерли-1.
Это бы конечно надо, но задача кодогенерации довольно изолированная, ее можно начать решать до общей концепции компилятора... С другой стороны, надо выбрать API кодогенерации до начала основной работы, потому-то и спешка такая.
M>Вобщем, наверное все мою мысль поняли — для включения любого члена в работу, нужен фундамент — он же потом будет наглядной документацией.
Здравствуйте, catbert, Вы писали:
C>Да в глобальном плане, насколько я понимаю, все удовлетворены немерле-1. Немерле-2 решает главные проблемы немерле-1, а это страшноватый код
Тогда вопрос: компилер будет переписываться полностью или у существующего немного подпилят код в сторону модульности?
M>>Вот уже Влад ввёл ExternalTypeInfo — почему экстернал? Разве в дотнете есть понятие "внешний тип"?
C>В дотнете и нет, есть в наверное в любом достаточно продвинутом компиляторе. "Внешний тип" — тип, определенный не в сборке, которая компилируется в данный момент, вот и все C> у Builder-ов, по определению, методов должно быть больше (ведь мы можем изменять билдеры в процессе компиляции/исполнения макросов, а External* иммутабельны по природе).
Я не вижу каких-то особых причин разделять практически единую сущность. Ну будет больше методов, лишнюю память же они не съедят! Да и extension methods вроде бы есть.
C>Это бы конечно надо, но задача кодогенерации довольно изолированная, ее можно начать решать до общей концепции компилятора...
Как я понял, Влад уже попробовал CCI и его возможностей достаточно. На форуме уже бросаются заготовки классов для метаданных, хотя как и где они будут использоваться — вопрос (думаю, не только для меня? ). Мне кажется, такой "быстропрактический" подход слишком быстрый. По сути, даже непонятно, что в компиляторе будет переписываться (см. вопрос выше).
Здравствуйте, matumba, Вы писали:
VD>>Завел соответствующий issues.
M>Я там перевод поставил комментом, но последние 2 пункта требуют пояснений — постороннему человеку не понять.
В последнем предложении я пропустил слово "называемую". Там должно было быть "так называемую логику подстановки параметров типов".
Поясню, что это значит на примере. Предположим у нас есть тип:
class A[T] { }
и его наследник:
class B[X] : A[X] { }
Если мы захотим получить тип A[X], то нам потребуется подставить вместо параметра типов T тип X. Это осуществляется путем рекурсивной замены. Тип Subst снабжается информацией о том какие параметры типов нужно заменять на какие. О методах возвращающих Subst и шала речь в том пункте. Но возможно этот пункт вообще лучше удалить. Дойдет дело до этим методов, тогда и будем отдельно объяснять.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>Я там перевод поставил комментом, но последние 2 пункта требуют пояснений — постороннему человеку не понять.
Пункт 3:
"3. Указанные классы (и их наследники) должны хранить ссылку на соответствующие объекты низлежащих API, но эта ссыла не должна быть доступна через публичный интерфейс."
Речь идет о классах о которых речь велась выше. Низлежащие API это: CCI Metadata, Mono Cecil, AbsIL из F#.
Короче должно быть что-тол вроде:
"3. This classes must keep reference to corresponding classes of underlying API and these references must not be visible outside."
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>Но наверное это к лучшему, потому что у меня возник вполне резонный вопрос: а нет ли смысла начать с конца? Т.е. сначала определить язык, его типы, как они будут совмещаться с дотнетовскими, вообще подробно расписать _существенные_различия_ Немерли с дотентом, а потом уже придумывать утилитные классы, читалки метаатрибутов и т.п.
Язык уже определен в первой версии. Во второй версии мы хотим сосредоточиться на следующих главных аспектах:
1. Снятие ограничений на расширение синтаксиса и семантики.
2. Упрощении создания собственных DSL-ей (как внутренних, так и внешних).
3. Качестве реализации.
4. Качестве API макросов.
5. Сделать компилятор и интеграцию независимыми от конкретной версии фрэймворка.
Отсюда все что касается системы типов и языка в общем-то известно.
M>Вот уже Влад ввёл ExternalTypeInfo — почему экстернал? Разве в дотнете есть понятие "внешний тип"?
Оно есть в компиляторах. Есть типы которые получаются путем парсинга исходников и типизации полученного AST, а есть типы из внешних сборок (подключенных к проекту).
M>Я бы сказал ровно наоборот: есть типы дотнета и какие-то специфичные для Немерли типы (варианты?),
Это не то. Такие типы назывались "Nemerle". Например, был тип "ExternalNemerleTypeInfo" — наследник ExternalTypeInfo".
M>которые всё равно никакими "внешними" не будут — будут точно так же загружаться из сборок как string или Dictionary.
Вот тип загружаемый из сборки и называется внешним. Причем вне зависимости от того немерловый он или дотнетный.
M>Затем, хорошо бы как-то набросать схемок (вплоть до скана карандашного рисунка) того, из чего будет состоять компилятор — абстрактные "парсер", "лексер" мы все знаем, а нужна именно наглядная схема кто и что делает, какими данными обменивается, где хранит внутренние данные и вход/выход. Без общего понимания нет смысла бросаться кодить даже тем, кто понимает внутренности Немерли-1.
Как раз парсера и лексера не будет . Бдут вездесущие PEG-макросы. Весь язык будет строиться из них. По сути это и есть парсер. Но компонентный и модульный.
VD>>Почему-то (к сожалению) работа с метаданными и генерацией кода не очень популярна.
M>Да пофиг, это ничуть не скучнее, чем хвостовая рекурсия — для такой нетривиальной задачи как компилер всегда найдутся интересные в реализации моменты. BLToolkit тоже в своём роде "стотыщный скучный маппер БД-объекты", а кода написано немало! M>Вобщем, наверное все мою мысль поняли — для включения любого члена в работу, нужен фундамент — он же потом будет наглядной документацией.
ОК, попробуем. Что касается системы типов, то я недавно залил базовые описания для ее интерфейсов и ключевых классов. Сейчас их можно наблюдать здесь.
Думаю, что их изучение может о многом рассказать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>Тогда вопрос: компилер будет переписываться полностью или у существующего немного подпилят код в сторону модульности?
С начало планировалось идти методом глубокого рефаторинга. Но одна из проблем текущей версии компилятора — черезмерная связанность, нарушение многих принципов ОО-дизайна. Как результат в компилятор стало очень сложно вносить изменения. Плюс компилятор довольно медленно компилируется, что так же усложняет его развитие.
Таким образом на сегодня решено все же переписывать компилятор использую его части в качестве основы и заготовок.
C>> у Builder-ов, по определению, методов должно быть больше (ведь мы можем изменять билдеры в процессе компиляции/исполнения макросов, а External* иммутабельны по природе).
M>Я не вижу каких-то особых причин разделять практически единую сущность. Ну будет больше методов, лишнюю память же они не съедят! Да и extension methods вроде бы есть.
Это разные сущности которые в определенный момент времени должны предоставлять одинаковый интерфейс (общий поднабор). Но задачи у них совсем разные. External* только скрывают детали реализации АПИ работы с метаданными и генерации ИЛ-а. А вот *Builder-ы предоставляют дополнительную функциональность. Они позволяют работать с АСТ и в то же время предоставляют интерфейс типов.
Сливать их не стоит. Будет туча методов которые будут файлить в одних условиях и работать в других. А это совсем плохо. Лучше иметь два типа имеющих общий базовый класс и при этом предоставляют разные возможности.
При этом вместо External* можно будет использовать *Builder если для *Builder-ов завершен этап предварительной типизации (выведены типы параметров методов и проведено построение иерархии типов). Это же позволит нам вместо ссылок на внешние сборки использовать ссылки на другие проекты того же солюшена.
C>>Это бы конечно надо, но задача кодогенерации довольно изолированная, ее можно начать решать до общей концепции компилятора...
M>Как я понял, Влад уже попробовал CCI и его возможностей достаточно.
Попробовать то попробовал. Но черт всегда кроется в деталях. А детали выявляются только в процессе реального использования.
M> На форуме уже бросаются заготовки классов для метаданных, хотя как и где они будут использоваться — вопрос (думаю, не только для меня? ). Мне кажется, такой "быстропрактический" подход слишком быстрый. По сути, даже непонятно, что в компиляторе будет переписываться (см. вопрос выше).
Дык мы имеем рабочий компилятор. Можно сказать что это прототип. Из него и берутся заведомо рабочие решения. Зачем же нам еще раз проползать на пузе все препятствия? Мы используем полученный опыт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>3) Механизмы типизации (за исключением алгоритма вывода типов)
Вывод типов тоже будет полностью переделан.
То что есть сейчас тормозной глюкодром.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _Eter_, Вы писали:
_E_>Есть пара вопросов:
_E_>* При реализации ExternalTypeInfo нужно брать реализацию из nemerle-1 и переделывать ее на новый лад, или писать по-новому?
Писать новую. Просто нужно реализовать NTypeInfo из проекта Core, а там уже будем смотреть чего не хватает.
_E_>* Создал свой клон для CCI. Я правильно понимаю, что нужно сделать отдельный проект? Сейчас я назвал его Core.CCI, может как-то по-другому?
CCI трогать не надо. Надо собрать его сборки и использовать уже их. Их нужно положить в ExternalDependencies.
Проект нужно создать для того чтобы разместить в нем реализацию классов из Core. Этот проект можно назвать MetadataReader.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вкратце описание типов которые нужно реализовать: VD>TypeInfo — описвает базовый абстрактный тип представляющий описание типа в компиляторе. TypeInfo описывает не воплощенный тип, т.е. тип без параметров типов. Его часто так же называют Type Constructor, от чего в компиляторе он частенько появляется в полях с именем tycon.
Изза ской архитектуры довольно таки много проблем с типизацией Дженериков. Даже в самом дотнете есть Type который без заданых дженерик парметров, но когда порождаеться класс (и объект) то создается новый тип, в котором Женериковские параметры уже проставлены.
Иожет и в n2 сделать наследник от TypeInfo для реализованных дженериков. А вообще надо всю систему типизации пересмотреть..
Здравствуйте, VladD2, Вы писали:
VD>1. Производить чтение метаданных каждой сборки в отдельном потоке (т.е. код должен быть по потоко-независимым, если это позволяет базовая библиотека).
Да тоже всегда думал, что компилятор немерле должен быть много потоковым...
PS. Постараюсь влиться в проект как можно скорее..
Здравствуйте, BogdanMart, Вы писали:
BM>Изза ской архитектуры довольно таки много проблем с типизацией Дженериков.
Можно привести пример этих проблем?
BM>Даже в самом дотнете есть Type который без заданых дженерик парметров, но когда порождаеться класс (и объект) то создается новый тип, в котором Женериковские параметры уже проставлены.
Я так понимаю что "в самом дотнете" — это значит в System.Reflection? Этот API не лучший пример для подражания.
BM>Иожет и в n2 сделать наследник от TypeInfo для реализованных дженериков.
Делать наследников TypeInfo смысла нет. Я думал об объеденении TypeInfo и FixedType, так как они действительно фактически являются единым целым и не мыслимы друг без друга. Но пока что не нашел для этого достаточно аргументов.
BM>А вообще надо всю систему типизации пересмотреть..
Над этим и работаем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
BM>>Иожет и в n2 сделать наследник от TypeInfo для реализованных дженериков.
H>Зачем чтобы была такая же путаница как в дотнете? H>Для воплощения типов сейчас используется FixedType.Class с параметрами или без.
С FixedType и TypeInfo сейчас не меньшая путаница. Я бы даже сказал — большая.
Если нам не помогут, то мы тоже никого не пощадим.
VD>CCI трогать не надо. Надо собрать его сборки и использовать уже их. Их нужно положить в ExternalDependencies.
VD>Проект нужно создать для того чтобы разместить в нем реализацию классов из Core. Этот проект можно назвать MetadataReader.
Я имел ввиду нужно ли в названии проекта отразить, что это реализация чтения метаданных на основе базовой библиотеки cci? Ранее вроде бы говорилось, что предполагается реализовать чтение метаданных на основе разных базовых библиотек, одна из которых cci. Будут ли все эти реализации находиться в одной сборке, или для каждой все-таки нужна своя сборка.
Здравствуйте, VladD2, Вы писали:
VD>Ну, как? Что-нибудь получается? Если есть вопросы, то лучше их задавать заранее
Вопросы относительно проекта Core:
Класс NMemberInfo абстрактный, но не содержит не то что абстрактных, а даже виртуальных методов. Все-таки его свойства и методы должны быть абстрактными?
Возможно в проекте Core должны быть также соответствующие абстрактные классы: NPropertyInfo, NFieldInfo, NEventInfo, NMethodInfo ?
в файле IMember.n опечатка: должно быть CustomAttributes вместо CastomAttributes
PS. Я могу сделать эти изменения в основной ветке, или в своем клоне
Здравствуйте, _Eter_, Вы писали:
_E_>Я имел ввиду нужно ли в названии проекта отразить, что это реализация чтения метаданных на основе базовой библиотеки cci?
А, да... это можно. Можно назвать ее MetadataReader.CCI.
_E_>Ранее вроде бы говорилось, что предполагается реализовать чтение метаданных на основе разных базовых библиотек, одна из которых cci. Будут ли все эти реализации находиться в одной сборке, или для каждой все-таки нужна своя сборка.
Конечно логично было бы чтобы они находились в отдельных сборках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Eter_, Вы писали:
_E_>Вопросы относительно проекта Core:
_E_> * Класс NMemberInfo абстрактный, но не содержит не то что абстрактных, а даже виртуальных методов. Все-таки его свойства и методы должны быть абстрактными?
Делай пока виртуальными. В принципе большую их часть можно реализовать прямо в этом классе. В принципе класс не очень то и нужен. Он ведь только интерфейс реализует.
_E_> * Возможно в проекте Core должны быть также соответствующие абстрактные классы: NPropertyInfo, NFieldInfo, NEventInfo, NMethodInfo?
Да проще, наверно, реализовывать интерфейсы напрямую. Хотя, если в реализациях будет общий код, то можно поступить и так.
_E_>в файле IMember.n опечатка: должно быть CustomAttributes вместо CastomAttributes
Сейчас поправим.
_E_>PS. Я могу сделать эти изменения в основной ветке, или в своем клоне
CastomAttributes — я уже поправил. Так что просто обновись. Остальное меняй как тебе надо. Если что потом отрефакторим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, VladD2, Вы писали:
J>каков смысл типа Nemerle2.Compiler.Subst?
Это тип используемый для подстановки параметров типов. Он позволяет заменить одни параметры типов другими. Пример его применения можно найти в комите 9508 (файл Typer.n). Там Subst используется для замены параметров типа алиаса (создаваемых директивой "type") на явно заданный список типов.
J>и на счет свойства NTypeInfo.AttributeTargets , я так понимаю — это свойство имеет смысл только для наследников System.Attribute ?
По всей видимости — да.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Так же прошу всех кто хочет работать над этой фичей скоординировать работу друг с другом. VD>Лучше всего было бы организовать общественный чат в Скайпе где и обсуждать все возникающие проблемы и идеи.
Как бы скоординировать работу? Мне сейчас не очень понятно, как работать: начал я что-то делать в своем клоне, а два других человека начали делать в своих, какой смысл нам делать одну и ту же работу?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _Eter_, Вы писали:
_E_>>На ревизии 5f2b02224b улетает ncc.exe
VD>Что значит "улетает"?
Происходит необработанное исключение. Причина видимо была в том, что у меня получились установлены две версии Nemerle: бета и RC. После того как я их обе снес и заново поставил только RC все заработало
Оптимально было бы связаться в одно и то же время по скайпу и обсудить детали. Просьба отписать в указанной ветке удобно ли обсуждать по скайпу и если да, то во сколько тебе будет удобнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Для начала личная просьба, занести в гугль-эканут информацию о рсдн-овском экаунте и наоборот. А то приходится искать корреляцию через поиск в почте. Тоже самое касается скайповского экаунта.
_E_>Как бы скоординировать работу?
Да, конечно.
_E_>Мне сейчас не очень понятно, как работать: начал я что-то делать в своем клоне, а два других человека начали делать в своих, какой смысл нам делать одну и ту же работу?
Как я понял реально CCI-ем занялись двое, ты и Jack128. Лучше всего будет пересечься по скайпу и обсудить детали. Если через скайп сложно, то можно и здесь все обсудить. Я уже отписал
Здравствуйте, _Eter_, Вы писали:
_E_>Как бы скоординировать работу? Мне сейчас не очень понятно, как работать: начал я что-то делать в своем клоне, а два других человека начали делать в своих, какой смысл нам делать одну и ту же работу?
Я потихонечку начну смотреть что вы оба уже успели сделать и выдавать отдельные замечания.
Здравствуйте, Jack128, Вы писали:
J>каков смысл типа Nemerle2.Compiler.Subst ? J>и на счет свойства NTypeInfo.AttributeTargets , я так понимаю — это свойство имеет смысл только для наследников System.Attribute ?
Посмотрел твой код. Есть несколько замечаний.
1. Классы реализации нужно поместить в отдельный проект (а не держать их в Core).
2. В тестах (да и вообще нигде) нельзя использовать полные пути. В качестве тестовых сборок используй Nemerle*.dll. Путь к ним получай программно, через переменные среды расширения. Если орпеделена переменная "%Nemerle%", то бери путь в ней, если нет, то используй "%ProgramFiles%\Nemerle". На всякий случай.... их резолв делается с помощью System.Environment.GetEnvironmentVariable().
3. В проекте периодически попадаются табуляции. Это не хорошо. В других местах отбивки делаются четырьмя (4) пробелами. Надо использовать два (2).
4. Используются неверные переносы операторов. Бинарные операторы переносятся на следующую строку. При указании типов надо ставить пробел как перед двоеточием, так и после него, т.е. не так "_host: SomeType", а так "_host : SomeType". В общем, внимательно прочти правила форматирвоания.
5. Значения лучше вычислять не в свойствах, а в конструкторах. Вычисляем значения свойств в свойствах, только если они возвращают большие объемы данных загрузку которых имеет смысл отсрочить. Обычно такие свойства имеют тип Seq[_]. Так значение свойства IsNumeric лучше вычислить в конструкторе (или при первом обращении и запомнить в поле).
6. По поводу свойства IReferencedAssembly.Types:
public Types : Seq[NTypeInfo]
{
get
{
def types = _assembly.GetAllTypes();
types.Map(CciNTypeInfo(_));
}
}
6.2. Полученный список нужно кэшировать, а не создавать при каждом запросе значения свойства. Это во-первых, расточительно, и во-вторых, будет создавать множество экземпляров оберток (CciNTypeInfo) для одного и того же типа, а этого лучше избежать. Для материализации списков большого размера лучше всего использовать privat-копии массивов. Ссылки на такие массивы ни в коем случае не отдавать наружу. Вместо этого нужно возвращать отдельный перечислитель (Seq).
6.2. Хот в данном случае список все равно нужно материализовать, но в общем случае, если свойство возвращает Seq, вычисление его значения нужно стараться отложить. Стало быть здесь нужно примерять не Map(), а MapLazy() или линковский Select(). Еще раз подчеркну, что в данном случае список все равно нужно материализовать.
6.3. Если не ошибаюсь, метод GetAllTypes() возвращает все типы. В том числе и вложенные. Нам же нужно возвращать только типы объявленные в пространствах имен (т.е. типы верхнего уровня). Вложенные типы должны быть доступны через соответствующие свойства NTypeInfo. Возможно потом мы добавим дополнительное свойство выдающее все типы. Но Types должен возвращать только верхнеуровневые.
Ну, и общее замечание по CCI. Работать с их интерфейсами напрямую обычно очень сложно и неудобно. Для облегчении жизни авторы CCI создали ряд классов-помощников. Например, TypeHelper для упрощения работы с типами. Вот список хэлперов выявленный поиском по следующему регуляроному выражению "class :iHelper":
* TypeHelper
* MemberHelper
* AttributeHelper
* ClrHelper
* UnitHelper
* MutableModelHelper
--------- нижеприведенные, видимо, к делу не относятся ---------
* HashHelper
* IteratorHelper
* ObjectModelHelper
Их имена говорят сами за себя. Просто открой солюшен Metadata.sln и посмотри описания их методов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>3. В проекте периодически попадаются табуляции. Это не хорошо. В других местах отбивки делаются четырьмя (4) пробелами. Надо использовать два (2).
Может в 2011-м году проще купить широкоформатный монитор?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>3. В проекте периодически попадаются табуляции. Это не хорошо. В других местах отбивки делаются четырьмя (4) пробелами. Надо использовать два (2).
IT> Может в 2011-м году проще купить широкоформатный монитор?
Ты сегодня не с той ноги встал?
Есть правила форматирования кода и их нужно выполнять не смотря на вероисповедание, размер монитора и прочих прелестей. Большинство высказалось за 2 пробела, значит так тому и быть.
ЗЫ
Что до мониторов, то с ноутбуком монитор таскать не будешь. Да и монитор тут не причем. Немерл располагает к написанию кода "в строку". Провоцировать бессмысленное удлинение строк нет смысла. Раз выбрали проблемы, то их будет ровно два.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Есть правила форматирования кода и их нужно выполнять не смотря на вероисповедание, размер монитора и прочих прелестей. Большинство высказалось за 2 пробела, значит так тому и быть.
А где на них можно посмотреть?
VD>Что до мониторов, то с ноутбуком монитор таскать не будешь. Да и монитор тут не причем. Немерл располагает к написанию кода "в строку". Провоцировать бессмысленное удлинение строк нет смысла. Раз выбрали проблемы, то их будет ровно два.
А четыре обсуждали?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>Есть правила форматирования кода и их нужно выполнять не смотря на вероисповедание, размер монитора и прочих прелестей. Большинство высказалось за 2 пробела, значит так тому и быть.
IT>А где на них можно посмотреть?
VD>>Я там плюсик не поставил, так как мне по фигу 2 пробела или таб. Но если речь идет о пробелах, то мой выбор так же 2 пробела.
IT>Мда. Всё остальное не смертельно. Но 2 пробела это вы, конечно, отмочили. Табы надо было выбирать. Это же азы опен-соурса.
Не надо собственные предпочтения выдавать за выбор Опенсорса. В открытых проектах самые разные соглашения используют.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Eter_, Вы писали:
_E_>Как бы скоординировать работу? Мне сейчас не очень понятно, как работать: начал я что-то делать в своем клоне, а два других человека начали делать в своих, какой смысл нам делать одну и ту же работу?
Здравствуйте, VladD2, Вы писали:
VD>Для начала личная просьба, занести в гугль-эканут информацию о рсдн-овском экаунте и наоборот. А то приходится искать корреляцию через поиск в почте. Тоже самое касается скайповского экаунта.
Добавил в google-акаунт имя rsdn-акаунта в качестве Home page
А в скайпе написал в разделе "Обо мне". Так нормально будет?
VD>Как я понял реально CCI-ем занялись двое, ты и Jack128. Лучше всего будет пересечься по скайпу и обсудить детали. Если через скайп сложно, то можно и здесь все обсудить. Я уже отписал
Jack128. Надеюсь, что он откликнется здесь в ближайшее время.
VD>ЗЫ
VD>Просьба отписать можешь ли ты общаться в скайпе и если да, то в какое время предпочтительнее общаться.
Могу обсудить через скайп, только через сообщения, микрофона у меня нет. В сети обычно по вечерам, хотя на выходных бываю и утром.
На форуме уже бросаются заготовки классов для метаданных, хотя как и где они будут использоваться — вопрос (думаю, не только для меня? 
).
Если нам не помогут, то мы тоже никого не пощадим.
Может в 2011-м году проще купить широкоформатный монитор?
