parser

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

 

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

Ответ

G_Z 15.11 19:35

Суть в том, что в случае ^if парсер не пытается искать переменную в текущем контексте, а возвращает оператор. В теории наверное можно разбить получение переменной на 2 части - получение в локальных переменных и все остальное, и вместо такого:

написать что-нибудь такое
А нельзя, имея список локальных переменных, исключать их из поиска операторов вообще?
Их не много и большинство вызовов не будет затронуто.

Есть вариант с каким-нибудь префиксом a-la $local:var, но элегантность сомнительна.
По мне так проще не определять в main мешающих методов.
Разумеется.

Но:
1. имена операторов не всегда подконтрольны и сходу известны — в системе может появиться сторонний код с операторами (плохая идея, тем не менее), что может вызвать проблемы далеко не сразу и приводить к крайне трудноуловимым ошибкам, особенно если оператор похож на метод и принимает похожие параметры;
2. в процессе работы над кодом в классах можно случайно пересечься названиями параметров с уже имеющимися методами и, опять же, столкнуться с трудноуловимыми ошибками;
3. переносимость кода непредсказуема.

В pf2 мы с Олегом договорились для устранения подобных проблем везде использовать $self и это помогает от конфликта методов фреймворка с операторами непредсказуемой среды, в которой может работать фреймворк, но в обсуждаемой ситуациями с параметрами и это не поможет.

Фактически, это уязвимость. Хоть и редко проявляющаяся.

В моём случае совпали имена link метода генерации маршрутов модулей в pf2 и оператора в auto.p, выводящего ссылку файла стека необработанного исключения.
Я, конечно, конфликты устраню, но прежних сухости и комфорта уже нет.