AOP in simple PHP that does not require any PECL extensions (Go!) - How?

Question

There is a Go framework ! Aspect-Oriented Framework for PHP

And this is done in simple PHP, it does not require any extensions of PECL and DI containers.

What else can be integrated with any existing PHP frameworks and libraries (with or without additional configuration).

And there are no pointcut runtime checks, there is no parsing of annotations at runtime, no evals and __call methods, no slow proxies and call_user_func_array (). Fast bootstrap process (2-20 ms) and call recommendations.

So, I am very impressed, but what I want to know is how it works?

These items that I have listed here ...

I looked at github and the official site and some other articles, but could not find any specific information on how this works (in general and in particular).

I so want to know how it works? How is this implemented?

Answer 1

This structure uses many hidden tricks to do its job, but if we look from the view of the bird, the process can be described as follows:

• The current version of the AOP mechanism is designed to work closely with the composer, so it completes the composer loader with its own proxy. From now on, AOP knows which class should be loaded and where to look for the source code.
• When a Foo class is loaded from the Foo.php file, AOP transfers it to a special filter stream as follows: include 'php://filter/read=go.source.transforming.loader/resource=Foo.php'; . You can read more about this stream filter in the 'php: // stream' manual
• At this moment, the class is not loaded into the PHP memory, but the structure already knows the contents about it and can perform analysis or even modification of the source code.
• The source code, then designated, is parsed in AST via nikic / PHP-Parser , and then a static reflection of this code is created (still without loading this file into PHP memory) via goaop / parser-reflection
• The engine checks all registered point points from aspects and performs the conversion of the original Foo class: it is renamed to Foo__AopProxied , and a new file with the Foo extends Foo__AopProxied class Foo extends Foo__AopProxied is created in the cache.
• Then the engine starts the autoloader to load this class from this new file instead of the original one, so you have the original class name, but with additional logic from the tips. It looks like automatic decorator generation at runtime.

Of course, this is just a small amount of information, because implementing AOP in pure PHP was a very difficult task, and I tried many times before finding a working solution, so it may be interesting to dig out the source code to find hidden stones :) Some information is also available in my PhpSerbia will talk about cross-cutting issues in PHP , you can watch it for a better understanding (sorry for my English).

We are also working on documentation for frameworks, so if you want to do it better just send us a PR to the official documentation.

You should also use the PhpStorm plugin, which provides many features for developers who use AOP in PHP projects.