parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Замусоривание MAIN у нас описано в уроках...

Sumo 22.11.2015 08:47 / 22.11.2015 08:51

... как стандартный метод разработки. Там очень много интересных «операторов» вводится в примерах: greeting, body, calendar, navigation, footer, header. Как я вижу по форуму, очень многие разработчики используют MAIN как основу приложения и не задумываются о «замусоривании» и что любая из функций MAIN может «перекрыть» метод внешнего класса.

Чтобы избежать проблем мы должны либо все выносить в классы, добавляя в MAIN только один оператор main:
@main[]
  $app[^App::create[...]]
  ^app.run[]
Либо ходить по минному полю, если нам нужен микс из встроенного в Парсер фреймворка вокруг MAIN и пользовательских классов. Возможно, это стоит описать в документации: либо живите в MAIN, либо уходите в классы.
Что можно попробовать сделать - отселить операторы в отдельный namespace, чтобы уменьшить вероятность конфликта.
...
Для совместимости можно например сделать так, что по умолчанию операторы будут жить в main, но опционально можно поменять имя класса операторов.
Оставлять ситуацию как есть точно нельзя. Миша предлагал девять лет назад варианты решения (http://www.parser.ru/forum/?id=57532):
- "операторы" объявляются иначе, например: @@foreach[hash;...]
- сделать чтобы операторами были не методы класса MAIN, а методы какого-нить ещё класса с фиксированным именем (OPERATORS?). неудобство: их не разнести по нескольким файлам, которые удобно @USE/^use[] (например не все операторы мне нужны в этой ветке сложного if или операторы написанны разными людьми хочется использовать в проекте).
- плюс к предыдущим сделать чтобы MAIN был неявным родителем любого пользовательского класса и соотв. поиск методов (но не переменных) происходил бы как обычно: сначала ищется метод класса, потом метод родительского класса, ... в конце - неявного родителя MAIN.

Я бы предложил сделать это все одной синтаксической конструкцией — @operator:foreach[..] — которая объвляет оператор в неявном внутреннем пространстве имен для операторов. И добавить метод ^reflection:operatros[], который возвращает список всех операторов.
Ну и в любом случае это не bug. :)
На мой взгляд это ошибка дизайна, которую мы получили в наследство от второго Парсера, где все макросы были в одном пространстве имен. :)