oop — AOP в простом PHP, который не требует никаких PECL-расширений (Go!) — Как?

Question

oop — AOP в простом PHP, который не требует никаких PECL-расширений (Go!) — Как?

Существует структура под названием Идти! Аспектно-ориентированный фреймворк для PHP

И он сделан на простом PHP, для работы не требуются PECL-расширения и DI-контейнеры.

Более того, его можно интегрировать с любыми существующими PHP-фреймворками и библиотеками (с дополнительной конфигурацией или без нее).

И нет никаких проверок во время выполнения контрольных точек, нет разбора аннотаций во время выполнения, нет методов evals и __call, нет медленных прокси и call_user_func_array (). Быстрый процесс начальной загрузки (2-20 мс) и вызов рекомендаций.

Так что я очень впечатлен, но я хочу знать, как это на самом деле работает?

Эти моменты, которые я перечислил здесь …

Я посмотрел на github и на официальном сайте, и некоторые другие статьи, но не смог найти никакой конкретной информации о том, как это работает (в целом и в частности).

Я так хочу знать, как это работает? Как это было реализовано?

6

aop frameworks goaop oop php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Эта структура использует много скрытых трюков для выполнения своей работы, но если мы посмотрим с высоты птичьего полета, то процесс можно описать следующим образом:

Текущая версия движка AOP предназначена для тесной работы с composer, поэтому она включает в себя загрузчик composer с собственным прокси. С этого момента AOP знает, какой класс должен быть загружен и где искать его исходный код.
Когда какой-то класс Foo загружается из файла Foo.phpAOP оборачивает его в специальный поток фильтра следующим образом: include 'php://filter/read=go.source.transforming.loader/resource=Foo.php';, Вы можете прочитать больше об этом фильтре потока в руководство ‘php: // stream’
В этот момент класс не загружается в память PHP, но фреймворк уже знает о его содержимом и может выполнять анализ или даже модификацию исходного кода.
Исходный код затем токенизируется, анализируется в AST через nikic / PHP-Parser библиотека, а затем генерируется статическое отражение этого кода (все еще без загрузки этого файла в память PHP) через goaop / анализатор отражения
Движок проверяет все зарегистрированные контрольные точки по аспектам и выполняет преобразование исходного класса Foo: переименован в Foo__AopProxied и новый файл с классом Foo extends Foo__AopProxied генерируется в кеше.
Затем Engine направляет автозагрузчик загрузить этот класс из этого нового файла вместо исходного, чтобы у вас было оригинальное имя класса, но с дополнительной логикой из советов. Это похоже на автоматическую генерацию декоратора во время выполнения.

Конечно, это лишь небольшой объем информации, потому что реализация AOP в чистом PHP была очень сложной задачей, и я много раз пытался найти подходящее решение, поэтому может быть интересно покопаться в исходном коде, чтобы обнаружить скрытые драгоценные камни 🙂 Немного информации также доступна в моем PhpSerbia говорит о сквозных проблемах в PHP, Вы можете посмотреть его для лучшего понимания (извините за мой английский).

Также мы сейчас работаем над документацией для фреймворка, поэтому, если вы хотите улучшить его, просто отправьте нам PR на официальная документация.

Вам также следует использовать плагин PhpStorm, который предоставляет множество функций для разработчиков, которые используют AOP в проектах PHP.

10