Как стать автором
Обновить

Комментарии 17

Отличная идея и реализация. Вопрос только в том, а можно ли как-то кешировать результаты, вместо того, чтобы каждый раз в рантайме гонять аннотатор с runkit? Например, если файл не поменялся, вгружать уже сгенерированый класс со всеми зарегистрированными обработчиками.
Над ускорением думаю. Первое, что можно сделать — закешировать результат обработки php-doc и методов заменителей в apc. Это снизит время разбора. Как сохранить уже готовые классы пока не придумал.
Относительно производительности данные появятся через некоторое время, когда интегрирую решение в проект, на котором можно будет оценить скорость работы и необходимость в оптимизации.
Чтение аннотаций хорошо реализовано в Doctrine 2, от туда можно взять все необходимое для работы с ними + новые аннотации так же элементарно создаются. Не требуют компиляции доп. модулей, да и кэширование, по-моему, так уже реализовано. Не смотрели в эту сторону?
Хотя кеширование и runkit все равно, наверное, придется использовать в Вашем случае.
Аннотации сейчас практически все читают через PHP Reflection, Doctrine не исключение. С этим проблем нет. Модуль runkit в данном случае используется для замены кода «на ходу». Основное время уходит на замену кода и его построение. Построение можно закешировать в APC. На продакшене, где код меняется не часто это позволит не парсить аннотации до сброса кеша.
Да, с этим понятно. А если не менять код на ходу, а использовать прокси-классы, как делает опять тот же Doctrine? Т.е. генерировать их заранее, класть в папочку и использовать уже от туда. Просто библиотека Ваша конечно же будет многим полезна, но очень сильно мешает компиляция сторонних модулей, в мире shared-хостингов использовать ее будет очень трудно.
Такие решения уже есть. Например FLOW3. Другое дело, что интегрировать целый фреймворк в уже готовый проект довольно сложно. Ещё как вариант — phpAspect. Он тоже генерирует прокси-классы.
В данном случае было интересно сделать решение работающее именно на лету и сравнить с существующими.
Было бы интересно посмотреть сравнительную статейку этих решений с Вашими, в том числе с тестами производительности.
Я планирую заняться тестированием производительности в течении нескольких ближайших дней, когда интегрирую решение в проект. Больше всего интересует будет ли разница и насколько значительная с phpAspect. Он ближе всего по духу (в плане синтаксиса).
if (isset(self::$cache[$options[0]])) — лучше array_key_exists. Метод может вернуть null, который игнорит isset.
Спасибо, исправил.
Честно говоря, немного запутался, когда увидел «Around». Вызов аннотатора «около» функции. Всё-таки это замена, наверное лучше что-то вроде instead использовать. Вообще, интересная штука. Можно примеры практического использования? Событийную модель на основе такого неплохо реализовывать, но не мешает ли код, например, юнит-тестам?
Названия советов before, after и around вместе с их поведением заимствованы из AspectJ. Везде, где я встречал АОП, оперировали именно этими названиями. Примеры применения я привёл в статье: кеширование, логирование, проверка прав доступа, реализация роутинга. Есть мысли реализовать Dependency injection. События, кстати, тоже хорошая идея.
По поводу unit-тестов. А как оно должно помешать? Естественно тесты нужно писать с учётом влияния советов на результат работы функции. В остальном никаких отличий нет. Это же всего лишь способ сделать из много скучного кода мало скучного кода.
В примерах не показано про $this, работает он в обработчиках?
Внутри обработчика $this ссылается на объект класса в котором определён обработчик. Получить доступ к объекту на метод которого навешан обработчик можно через параметр $point. Это массив. Для статических методов он имеет вид array('ClassName', 'methodName'); для методов объектов он имеет вид array(&$this, 'methodName'); Но в данном случае обращение к объекту идёт «снаружи». Т.е. доступа к приватным свойствам и методам не будет.
АОП интересная тема. Года 2 назад увлекался этой идеей в рамках PHP. Из современного:
1) Недавно вышел экстеншен для aop
2) Для PHP есть очень неплохой sf2 бандл (который в общем-то и отдельно можно попробовать использовать )
3) Аннотации все таки лучше использовать в DoctrineStyle
Сейчас, кстати, снова появилась мысль собрать это все, чтобы оно выглядело примерно так (3я часть доклада)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.