Comments 7
Немного недопонял, а что мешает эти шаблоны сразу превращать в код на Go?
Ничего не мешает, кроме того, что это придётся реализовывать и поддерживать в дополнение к динамической подгрузке, так динамические проверки удобны для тех, кто работает с PHP и не хочет/не может собирать Go. А ещё это полезно в окружениях, где есть линтер, но нет Go тулчейна.
Нужно учитывать, что это линтер для PHP, а Go здесь — деталь реализации. Поэтому требовать от людей наличия Go тулчейна для использования этой фичи может быть слишком. :)
Компиляция шаблонов — это оптимизация, а пока у нас нет проблем с производительностью. Даже если умножить на 10 количество текущих шаблонов, работает очень быстро, при этом нет гарантии, что у нас когда либо действительно будет x20 шаблонов.
Например, для шаблона $_? $x: $x; кажется известно заранее какой конкретный узел AST «слушать».
В текущей реализации тоже не сложно запускать шаблон только для тернарных операторов. По-моему сейчас он в группе условных выражений, но не сложно довести отображение к 1-to-1, но опять же, рановато оптимизировать, как по мне.
Динамика просто удобнее или есть технические препятствия?
Я бы сказал, динамика даже мне удобна для отладки, когда экспериментируешь. Компиляция шаблонов была бы интересной дополнительной фичей, но вытеснить динамические правила она, думаю, не должна. Для совсем-совсем критичных к производительности проверок всегда можно написать обычное расширение линтера на Go, без использования "правил".
Есть чатик https://t.me/noverify_linter, где обсуждаем статический анализ и сам NoVerify.
В идеале это должно стать community чатом проекта, где голоса пользователей и контрибьюторов могут быть услышаны более оперативно и в менее формальной обстановке, чем GitHub issues.
Присоединяйтесь, если интересен статический анализ PHP (другие линтеры там тоже обсуждаем и сравниваем). :)
Может быть стоит переходить на типизированные языки при разработке сервисов?
Как добавить проверки в NoVerify, не написав ни строчки Go-кода