VD>Если надо просто скрыть тип, то ему можно изменить атрибуты доступа.
а можно добавить флаг "не компилировать" или "не включать в сборку"?
мне тоже хочется на базе имеющегося класса строить его близкий, но не точный аналог.
с последующей заменой.
Re[3]: Можно ли удалить объявленный класс макросом?
Здравствуйте, _Claus_, Вы писали:
VD>>Если надо просто скрыть тип, то ему можно изменить атрибуты доступа.
_C_>а можно добавить флаг "не компилировать" или "не включать в сборку"? _C_>мне тоже хочется на базе имеющегося класса строить его близкий, но не точный аналог. _C_>с последующей заменой.
Максимум что можно сделать, чтобы не нарушать целостность — автоматически выкидывать приватные классы на которые нет ссылок из кода. И то может оказаться, что люди к ним доступ через рефлексию ведут.
Ну, или помечать классы атрибутом и давать ошибку если есть ссылки.
Но это не хилый анализ еще сделать надо будет.
Меж тем это совершенно неправильный подход. Не стоит удивлять пользователей. А исчезновение типа — это магия.
В Н2 будет доступно любое синтаксическое расширение по которому можно будет сгенерировать что угодно, но удаления типов тоже не предвидится. При этом синтаксическое расширение не обязано будет быть классом или методом, как сейчас. Это будет произвольная грамматика встроенная в одну из точек расширения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Можно ли удалить объявленный класс макросом?
VD>Меж тем это совершенно неправильный подход. Не стоит удивлять пользователей. А исчезновение типа — это магия.
абсолютно согласен. но если в классе надо заменить поле, то так можно было бы обойти.
лучше бы иметь возможность добраться к описанию до формирования полей.
или как то дать возможность и не только добавлять, но и редактировать.
насколько я понимаю, в этом нет особой сложности, кроме разве что идеологической.
VD>В Н2 будет доступно любое синтаксическое расширение по которому можно будет сгенерировать что угодно, но удаления типов тоже не предвидится. При этом синтаксическое расширение не обязано будет быть классом или методом, как сейчас. Это будет произвольная грамматика встроенная в одну из точек расширения.
в Н2 верю. хотелось бы, чтобы новые нужные фичи не откладывались до Н2.
Re[5]: Можно ли удалить объявленный класс макросом?
Здравствуйте, _Claus_, Вы писали:
_C_>абсолютно согласен. но если в классе надо заменить поле, то так можно было бы обойти.
Заменять что либо — тоже не правильный подход. Нужно толкьо дополнять. Создавай вместо поля сразу нужное свойство, а нужную информацию навешивай на него атрибутами. Будет понятно, интуитивно и без удивления.
_C_>лучше бы иметь возможность добраться к описанию до формирования полей.
В условиях Н1 лучший подход — не выпендриваться и не пытаться эмулировать свой синтаксис разными хаками.
VD>>В Н2 будет доступно любое синтаксическое расширение по которому можно будет сгенерировать что угодно, но удаления типов тоже не предвидится. При этом синтаксическое расширение не обязано будет быть классом или методом, как сейчас. Это будет произвольная грамматика встроенная в одну из точек расширения.
_C_>в Н2 верю.
Это твои проблемы.
_C_>хотелось бы, чтобы новые нужные фичи не откладывались до Н2.
Организовать парсинг произвольных конструкций в Н1 практически невозможно. Для этого нужно менять парсер. Разработка такого парсера — это сама по себе хайтековская задача. Тот парсер что разрабатывается для Н2 и есть такой парсер. Когда он будет доведен до ума можно будет начать работа над Н2. Прикручивать его к Н1 смысла нет. Ведь в итоге получатся сильные изменения в макросистеме, т.е. ломающие измнения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Можно ли удалить объявленный класс макросом?
VD>Заменять что либо — тоже не правильный подход. Нужно толкьо дополнять. Создавай вместо поля сразу нужное свойство, а нужную информацию навешивай на него атрибутами. Будет понятно, интуитивно и без удивления.
Я написал патч, позволяющий удалить поле, метод TypeBuilder.RemoveParsedMember. чтобы проверить сложность. в сумме строк 15 всех модификаций. Он решает и мою проблему, и другую, когда надо удалять или трансформировать. Если пришлю — добавишь?
_C_>>лучше бы иметь возможность добраться к описанию до формирования полей.
VD>В условиях Н1 лучший подход — не выпендриваться и не пытаться эмулировать свой синтаксис разными хаками.
Не выпендриваюсь. Сокращение описания — разумная вещь. И как ты можешь убедиться приходит в голову не мне одному.
И довольно странно, что такая мощная система метапрограммирования вдруг спотыкается на тривиальном моменте.
Это говорит о том, что N мало используется. потому что развитие диктуют именно практические потребности.
_C_>>в Н2 верю. VD>Это твои проблемы.
_C_>>хотелось бы, чтобы новые нужные фичи не откладывались до Н2.
VD>Организовать парсинг произвольных конструкций в Н1 практически невозможно. Для этого нужно менять парсер. Разработка такого парсера — это сама по себе хайтековская задача. Тот парсер что разрабатывается для Н2 и есть такой парсер. Когда он будет доведен до ума можно будет начать работа над Н2. Прикручивать его к Н1 смысла нет. Ведь в итоге получатся сильные изменения в макросистеме, т.е. ломающие измнения.
Н1 не исчерпал еще своего потенциала. можно вполне здесь решать текущие задачи без H2 — парсинга. тем более что других вариантов нет.
Re[6]: Можно ли удалить объявленный класс макросом?
VD>> Прикручивать его к Н1 смысла нет.
_C_>еще как есть. прикручивание новых возможностей к N1 — гарантия того, что они будут и в N2. чтобы потом все не отодвинулось до N3.
Бездумное перекручивание возможностей гарантия того, что скоро вместо языка будет помойка. В Н2 АПИ компилятора предполагается координатор пересмотреть. При это будет создана новая архитектура и новые подходы к решению задач выявленных в Н1.
Так что прежде чем что-то добавлять какие-то изменения в Н1 надо сто раз отмерить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Можно ли удалить объявленный класс макросом?
Здравствуйте, _Claus_, Вы писали:
_C_>Я написал патч, позволяющий удалить поле, метод TypeBuilder.RemoveParsedMember. чтобы проверить сложность. в сумме строк 15 всех модификаций. Он решает и мою проблему, и другую, когда надо удалять или трансформировать. Если пришлю — добавишь?
В наше время делают пул-реквесты, а не патчи присылают.
Но прежде чем что-то делать или присылать это нужно как следует обсудить. Вред от непродуманной фичи может быть куда больше чем польза. А лично я в данной фиче сомневаюсь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Можно ли удалить объявленный класс макросом?
VD>Но прежде чем что-то делать или присылать это нужно как следует обсудить. Вред от непродуманной фичи может быть куда больше чем польза. А лично я в данной фиче сомневаюсь.
именно поэтому и не прислал. будет там болтаться, людей раздражать. а фича нужная, для чего уж писано. если не добавлять фичи, диктуемые практическими потребностями — какие тогда добавлять? а если диктовать, какие потребности правильные, а какие нет, то кто же захочет всерьез использовать Н?
мало ли, что завтра ты, спросонья, решишь..
Re[8]: Можно ли удалить объявленный класс макросом?
VD>Так что прежде чем что-то добавлять какие-то изменения в Н1 надо сто раз отмерить.
когда то слышал твои слова, что мы добавляем, если оно ничего не нарушает и никому не мешает. на видео-лекции.
а то что хочу добавить — макротипы — так отсутствие их удивлять должно, а не возможность присутствия.
в N1 добавить это можно. не такое большое дело. лично я пока обойдусь. а функционал Zdb так половинчатым и останется.
Re[9]: Можно ли удалить объявленный класс макросом?
Здравствуйте, _Claus_, Вы писали:
_C_>именно поэтому и не прислал. будет там болтаться, людей раздражать. а фича нужная, для чего уж писано. если не добавлять фичи, диктуемые практическими потребностями — какие тогда добавлять? а если диктовать, какие потребности правильные, а какие нет, то кто же захочет всерьез использовать Н?
Показывай код, фича интересная, я согласен, тут надо рассмотреть варианты, решает ли проблему, какие могут быть подводные камни.
