Z>просто указать, что макра create доступна только внутри макросов up и down.
Макрос — это код который запускается для раскрытия. Если ты сможешь в этом коде как-то закодировать свою информацию — то да. Но в твоей постановке задачи — это невозможно. В прочем, можно конечно получить все тело текущего метода и проанализировать его, но это оверкил.
Z>На выделенный идентификатор хотетелось бы иметь автокомплишен, их достаточно много будет для удержания в голове.
Как я тебе уже отвечал, комлит будет если макрос сгенерирует код порождающий то что должно комплититься.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
// код миграции
CreateTable("Test", t => {
t.Integer("Id");
// контроль доппараметров тоже хочется сделать, для каждого типа свой набор
// может быть именованные параметры? можно ли их опускать?
t.String("Val", new (length = 10, default = "Str"));
});
// некоторый сахар который уже работает, студия дает автокомплишен для методов
create Test t => {
t.Integer("Id");
t.String("Val", new (length = 10, default = "Str"));
};
// хочется
create Test
{
Id : int;
Val(length = 10) : string = "Str";
};
Можно ли указать, область применимости макры? например только в методах Up, Down классов наследников MigrationBase?
Получится ли включить поддержку студии для варианта "хочется"? Если нет, как лучше задизайнить? Ну и вообще любые варианты приветствуются.
Здравствуйте, Ziaw, Вы писали:
Z>Можно ли указать, область применимости макры? например только в методах Up, Down классов наследников MigrationBase?
Конечно, можно проверять в каком методе происходит работа макроса и проверять, является ли текущий тип наследником MigrationBase. Но вообще, имхо, такие ограничения неудачная идея. Макросы строго типизированы — пусть компилятор сам разбирается в типах.
Да еще, может кто даст дельный совет по проблеме:
Код проекта не будет компилироваться без валидной БД. By design. Миграции же должны, иначе мы не получим валидную БД. Это в принципе решается отдельной тулзой которая скомпилит только файлы миграций, но в них пользователь может начать использовать все что угодно и непонятно где это все искать. Как вариант — вынести миграции в отдельный проект, но не хочется.
Здравствуйте, hardcase, Вы писали:
H>Конечно, можно проверять в каком методе происходит работа макроса и проверять, является ли текущий тип наследником MigrationBase.
Да нет, я думал в штатном режиме. Например чтобы один макрос мог быть только внутри другого.
H>Но вообще, имхо, такие ограничения неудачная идея. Макросы строго типизированы — пусть компилятор сам разбирается в типах.
Вобщем-то ты прав. Те же рельсы практически не имеют защиты от дурака.
Здравствуйте, Ziaw, Вы писали:
Z>Можно ли указать, область применимости макры? например только в методах Up, Down классов наследников MigrationBase?
Не понял вопроса.
В смысле проанализировать имя метода в котором раскрывается макрос?
Z>Получится ли включить поддержку студии для варианта "хочется"? Если нет, как лучше задизайнить? Ну и вообще любые варианты приветствуются.
Опять ничего не понял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Вобщем-то ты прав. Те же рельсы практически не имеют защиты от дурака.
Защита от дурака — это система типов. Просто делай так чтобы твои макросы генерировали хорошо типизированные выражения которые будут не применимы в не других контекстах, а компилятор проверит это и выдаст сообщения об ошибках.
Z>Да, еще, как получить PExpr в выполняемом файле?
Что? Описывай задачи более развернуто. Лучше с примерами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Да еще, может кто даст дельный совет по проблеме: Z>Код проекта не будет компилироваться без валидной БД. By design. Миграции же должны, иначе мы не получим валидную БД. Это в принципе решается отдельной тулзой которая скомпилит только файлы миграций, но в них пользователь может начать использовать все что угодно и непонятно где это все искать. Как вариант — вынести миграции в отдельный проект, но не хочется.
Вот почему я и говорил, что лучше имать описание модели и по нему делать все что нужно. А эти ваши миграции — это в основном нагрузка пользователя ненужной и сложной работой.
С тваими миграциями или нужно иметь их интерпретатор в рантайме (ну или автоматический компилятор), или действительно выносить в отдельный проект. В принципе в этом нет ничего плохого или страшного. Даже хорошо, так как в этом же проекте может быть генератор классов-модели. Это позволит не тратить время на их построение при любом изменении проекта. При изменении БД придется просто перекомпилировать один проект и сразу же будет доступен интелисенс и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>Можно ли указать, область применимости макры? например только в методах Up, Down классов наследников MigrationBase?
VD>Не понял вопроса.
VD>В смысле проанализировать имя метода в котором раскрывается макрос?
Наверное этого будет достаточно, но я забью. Хотелось узнать можно ли в таком ситаксисе
up {
create Test
{
Id : int;
Val(length = 10) : string = "Str";
};
}
просто указать, что макра create доступна только внутри макросов up и down.
Z>>Получится ли включить поддержку студии для варианта "хочется"? Если нет, как лучше задизайнить? Ну и вообще любые варианты приветствуются.
На выделенный идентификатор хотетелось бы иметь автокомплишен, их достаточно много будет для удержания в голове.
Здравствуйте, VladD2, Вы писали:
VD>Защита от дурака — это система типов. Просто делай так чтобы твои макросы генерировали хорошо типизированные выражения которые будут не применимы в не других контекстах, а компилятор проверит это и выдаст сообщения об ошибках.
Не шибко внятное, типа метода не нашел например.
Z>>Да, еще, как получить PExpr в выполняемом файле?
VD>Что? Описывай задачи более развернуто. Лучше с примерами
Да тут я конечно перегнул с лаконичностью ) просто хотелось иметь возможность передать аст в проект который дебажится и посмотреть его структуру. Сложно писать анализатор того, что неизвестно как выглядит. Может быть из макры распечатеть его в удобном виде можно?
Здравствуйте, Ziaw, Вы писали:
VD>>Защита от дурака — это система типов. Просто делай так чтобы твои макросы генерировали хорошо типизированные выражения которые будут не применимы в не других контекстах, а компилятор проверит это и выдаст сообщения об ошибках.
Z>Не шибко внятное, типа метода не нашел например.
У меня ощущение, что я смотрю эпизод из "Звездных войн" с участием Ёды.
Какой пример нужен?
Z>Да тут я конечно перегнул с лаконичностью ) просто хотелось иметь возможность передать аст в проект который дебажится и посмотреть его структуру. Сложно писать анализатор того, что неизвестно как выглядит. Может быть из макры распечатеть его в удобном виде можно?
Ты можешь отлаживать сами макросы и смотреть на получаемый код прямо в Wath. Самый простой способ это сделать — воткнуть в код assert2(false); и нажать на Retry когда появится окно (во время компиляции).
Кроме того у любого куста АСТ (PExpr, например) есть метод ToString(). С его помощью можно получить текст (сгенерированный) макроса. Его можно прямо в код куда-то засунуть, если надо.
Кроме того при добавлении методов можно использовать не Define, а DefineWithSource (поищи его использование в коде компилятора и сниппетов). Это приводит к тому, что для добавленных таким образом методов будет сгенерирован исходный код по которому можно будет осуществлять отладку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>У меня ощущение, что я смотрю эпизод из "Звездных войн" с участием Ёды. VD>Какой пример нужен?
Загадка мастера Йоды раскрыта. Старый программист на форте он просто. Проедем этот этап, не хочется тратить время.
Z>>Да тут я конечно перегнул с лаконичностью ) просто хотелось иметь возможность передать аст в проект который дебажится и посмотреть его структуру. Сложно писать анализатор того, что неизвестно как выглядит. Может быть из макры распечатеть его в удобном виде можно?
VD>Ты можешь отлаживать сами макросы и смотреть на получаемый код прямо в Wath. Самый простой способ это сделать — воткнуть в код assert2(false); и нажать на Retry когда появится окно (во время компиляции).
VD>Кроме того у любого куста АСТ (PExpr, например) есть метод ToString(). С его помощью можно получить текст (сгенерированный) макроса. Его можно прямо в код куда-то засунуть, если надо.
VD>Кроме того при добавлении методов можно использовать не Define, а DefineWithSource (поищи его использование в коде компилятора и сниппетов). Это приводит к тому, что для добавленных таким образом методов будет сгенерирован исходный код по которому можно будет осуществлять отладку.
Ок, спасибо за хитрушки. Мне как раз текст не нужен, мне придется анализировать дерево, а для этого надо понять из чего оно состоит.
