Comments 7
Спасибо за статью.
Немного недопонял, а что мешает эти шаблоны сразу превращать в код на Go?
Грубо говоря вместо динамики «NFA» сразу получить нативный «DFA»?
Например, для шаблона $_ ? $x : $x; кажется известно заранее какой конкретный узел AST «слушать».
Динамика просто удобнее или есть технические препятствия?
Немного недопонял, а что мешает эти шаблоны сразу превращать в код на 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 (другие линтеры там тоже обсуждаем и сравниваем). :)

Что бы вк не делало, лишь бы не наводило порядок в разработке.
Может быть стоит переходить на типизированные языки при разработке сервисов?

Ты имеешь ввиду уйти от языка PHP. Ты, видимо не понимаешь как устроен бекенд Вконтакте?
У них движки на C/C++, транслятор PHP-binary-C++(kphp), kphpешный сервер на бекенде, который слушает определённые порты, может общаться с движками по RPC/TL бинарному протоколу с описанной схемой. А все сервисы на PHP. Ну и немного Go для каких-то отдельных сущностей, вроде отправки push-уведомлений

Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

10 November 2006

Location

Россия

Website

vk.com

Employees

1,001–5,000 employees

Registered

9 August 2008