incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: Starting with the Whiteboard Code
Date Sun, 12 Feb 2012 22:29:42 GMT

> 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.



















Mime
View raw message