I was working on something like an AspectJ implementation ...
Compile-time-AOP has the obvious problem that you can not load an
additional library at runtime into a container. That is one of the main
reason for the popularity of spring in java - it offered reasonably fast
AOP at runtime that allowed loading of jars at a significantly reduced
compile time. Of course Java is a different game than AS3: A typical
Java - serverside - application has a runtime that is a little longer
than the common swf.
What about the option that the compiler created something like:
var inst: MyClass = new (ASPECT_CACHE['com.mycompany.MyClass'] ||=
ASPECT_STRATEGY.getConstructor('com.mycompany.MyClass')) ();
In other words it had to replace all class references with this code.
This would bloat the swf size but I assume it is reasonably fast, faster
than for example replacing it with a function. Another thing on
performance is the current problem of dynamic proxy creation. If Proxies
need to be created then the whole startup will be delayed. It could be
pretty fast, admittingly not as fast as using directly baked proxies but
still: Pretty fast.
If the "Aspect Strategy" would be implemented with special statements to
pre-bake the custom classes that it modifies then it almost wouldn't
waste any startup time.
This way one could load regular swfs and they would still be treated
under the same aspect system that could be loaded at runtime. This would
also allow the system to be setup with an xml that is loaded for
example. I happened to find that pretty useful on various occasions.
If I'm not wrong, you did some deep experiments in DI and AOP, what can you say
about performences ? did you do measurements ? if yes, how ?
@Michael What about dependency injection. Does it need to be tightly coupled
to AOP? The difference between DI and AOP is to me that AOP will be used at
code that is not prepared for AOP while DI has to be marked for it.
I hope I am expressing myself right here:
AOP:
1) Intercept the creation of *any* class
2) Wrap the class with more functionality
3) Spit it out.
DI:
1) Intercept the creation of a *specific* class
2) Pre-fill various properties
3) Spit it out.
The difference being that you don't need a custom constructor logic for
property injection (most common type).
So: Do you think it would be possible to have a "less-complex" solution that
would just implement certain parts of DI?
yours
Martin.
