Ответ
G_Z 15.11.2020 19:35
Суть в том, что в случае ^if парсер не пытается искать переменную в текущем контексте, а возвращает оператор. В теории наверное можно разбить получение переменной на 2 части - получение в локальных переменных и все остальное, и вместо такого:
…
написать что-нибудь такое
А нельзя, имея список локальных переменных, исключать их из поиска операторов вообще?
Их не много и большинство вызовов не будет затронуто.
Есть вариант с каким-нибудь префиксом a-la
$local:var, но элегантность сомнительна.
По мне так проще не определять в main мешающих методов.
Разумеется.
Но:
1. имена операторов не всегда подконтрольны и сходу известны — в системе может появиться сторонний код с операторами (плохая идея, тем не менее), что может вызвать проблемы далеко не сразу и приводить к крайне трудноуловимым ошибкам, особенно если оператор похож на метод и принимает похожие параметры;
2. в процессе работы над кодом в классах можно случайно пересечься названиями параметров с уже имеющимися методами и, опять же, столкнуться с трудноуловимыми ошибками;
3. переносимость кода непредсказуема.
В pf2 мы с Олегом договорились для устранения подобных проблем везде использовать
$self и это помогает от конфликта методов фреймворка с операторами непредсказуемой среды, в которой может работать фреймворк, но в обсуждаемой ситуациями с параметрами и это не поможет.
Фактически, это уязвимость. Хоть и редко проявляющаяся.
В моём случае совпали имена
link метода генерации маршрутов модулей в pf2 и оператора в auto.p, выводящего ссылку файла стека необработанного исключения.
Я, конечно, конфликты устраню, но прежних сухости и комфорта уже нет.
