Здравствуйте, Ziaw, Вы писали:
Z>Я и не расчитывал, что хватит на все =) Я делаю прототип, главное сделать рабочие фичи и посмотреть как это будет в использовании. Потом уже можно пилить и оптимизировать все что угодно.
Потом у тебя будет два выхода из положения:
1. Выбросить прототип и написать все как следует.
2. Увязнуть в наспех слепленной архитектуре. (примерно, как это сейчас происходит с исходниками компилятора)
Так что на "пилить" лучше серьезно не рассчитывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, seregaa, Вы писали:
S>Для получения списка окон EnumOriginalCodeBlocks (наша реализация) запрашивает у координатора буфер, связанный со сгенерированным кодом и парсит его регулярными выражениями.
Ужас!
ЗЫ
Для хинтов можно попытаться пользоваться их координатором. Может он даст корректное обратное отображение. Тогда вывести хинт не составит труда.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Я и не расчитывал, что хватит на все =) Я делаю прототип, главное сделать рабочие фичи и посмотреть как это будет в использовании. Потом уже можно пилить и оптимизировать все что угодно.
VD>Потом у тебя будет два выхода из положения: VD>1. Выбросить прототип и написать все как следует.
Прототип движка миграции и генераторов моделей? Влад, там строк 50-100 кода завязано на драйвер. Сам драйвер был часа за 2-3 выдран из Януса и немного подрихтован. Это все можно выкинуть и переписать не напрягаясь, если что-то не устроит. Затрат будет точно не больше, чем я бы писал это с нуля, ибо сейчас у меня больше понимания по требованиям к этому драйверу. На данный момент он устраивает полностью.
Остальные фичи не должны завязываться на схему БД, они вообще не будут знать про этот драйвер.
VD>2. Увязнуть в наспех слепленной архитектуре. (примерно, как это сейчас происходит с исходниками компилятора)
Здравствуйте, Ziaw, Вы писали:
Z>>>Но для него нужен валидный nemerle синтаксис, чего хотелось бы избежать.
VD>>Можно пояснить эту мысль?
Z>
Z>[NRails.Macros.View]
Z>class MyPuperView
Z>{
Z>Код на моем DSL
Z>}
Z>
Z>Выделенное — синтаксический оверхед, особенно MyPuperView.
Как-то не ясно все же что было сказано в исходной цитате.
Что касается твоего гипотетического примера, то все зависит от того, что ты хочешь создать в итоге. Если речь идет о рекурсивных шаблонах а-ля стринг-темплэйт, то класс и методы как базовые элементы дизайна вполне удобны. Сам ДСЛ можно разместить на уровне тел методов.
Еще как варинат вообще не делать глобальных конструкций. Вместо этого можно поступить как в случае с $-строками — создаь макросы уровня выражений которые позволят сильно упростить трансформацию, а саму логику описывать в виде ординарного кода. Тогда вообще не придется менять конструкции верхнего уровня.
Ну, и конечно можно создать внешний ДСЛ. Только при этом главное не нарваться на ошибку допущенную в дизайне asp — когда шаблон превращается в монолитную простыню, а не является рекурсивной структурой. ХМЛ и ХТМЛ — это древесные структуры. А они идеально описываются рекурсией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Выделенное — синтаксический оверхед, особенно MyPuperView.
VD>Как-то не ясно все же что было сказано в исходной цитате.
Там сказано, что хотелось бы избежать синтаксического оверхеда во вьюхах, вызванного тем, что для решения задачи через макры требуется валидный Nemerle исходник.
VD>Что касается твоего гипотетического примера, то все зависит от того, что ты хочешь создать в итоге. Если речь идет о рекурсивных шаблонах а-ля стринг-темплэйт, то класс и методы как базовые элементы дизайна вполне удобны. Сам ДСЛ можно разместить на уровне тел методов.
В итоге я хочу имплементить SparkViewEngine или очень похожий по синтаксису.
VD>Еще как варинат вообще не делать глобальных конструкций. Вместо этого можно поступить как в случае с $-строками — создаь макросы уровня выражений которые позволят сильно упростить трансформацию, а саму логику описывать в виде ординарного кода. Тогда вообще не придется менять конструкции верхнего уровня.
Это плохой путь, вьюха должна выглядеть максимально приближенной к конечному результату. Самый ортодоксальный вариант — haml, все что отличается сильнее него будет неудобно в использовании. Основой должен быть шаблон, код пишется только в случае необходимости. Все рюшечки вокруг самого шаблона — оверхед. Кстати, насколько сложно сделать интеграцию для студии того фукнционала, который реализован asp.net? Пусть в том же стиле, генерится класс с разметкой #line и подсовывается компилятору.
VD>Ну, и конечно можно создать внешний ДСЛ. Только при этом главное не нарваться на ошибку допущенную в дизайне asp — когда шаблон превращается в монолитную простыню, а не является рекурсивной структурой. ХМЛ и ХТМЛ — это древесные структуры. А они идеально описываются рекурсией.
Все что нужно для этого — реализовать функции внутри шаблона и импорт других, в спарке это есть, пусть немного коряво.
Здравствуйте, VladD2, Вы писали:
S>>Для получения списка окон EnumOriginalCodeBlocks (наша реализация) запрашивает у координатора буфер, связанный со сгенерированным кодом и парсит его регулярными выражениями. VD>Ужас!
Реализация из питона для поиска окон использовала токенизатор, реализованный в компиляторе. Я по быстрому все это выкинул и на писал простейшее регулярное выржение — писать что то другое в тот момент не было смысла, т.к. еще не было известно, заработает ли поддержка ContainedLanguage вообще.
Предлагаешь использовать парсер Немерле? или обойтись стандартными string.Trim(), string.StartWith(), string.IndexOf() и т.д.?
VD>Для хинтов можно попытаться пользоваться их координатором. Может он даст корректное обратное отображение. Тогда вывести хинт не составит труда.
Для хинта нужны экранные координаты в пикселях, а координатор работает с текстовыми позициями. Да, перевести координаты второго буфера обратно в координаты первого можно, но вот c экранными координатами проблема.
Наша реализация хинтов для определения экранных координат использует view, переданный NemerleSource-у в метод GetDataTipText(IVsTextView view, TextSpan[] textSpan, out string hintText). В случае соурса, связанного со сгенерированным кодом, в качестве вью используется наша затычка, которая не умеет GetPointOfLineColumn(). Я решил проблему так: запрашиваю у студии вью, активное на данный момент и использую его для определения координат хинтов:
