Wednesday, September 14, 2011
Released: AS3Commons-Bytecode version 1.0!
So, its been more than a year in the making. If I check the changelog, the first commit of as3commons-bytecode was done at the 27th of June 2010.
I've decided to call this release v1.0. I could think of another thousand things to be tweaked and improved but at a certain moment there needs to be a first final release :)
This certainly doesn't mean the library is now finished, I will keep on tweaking and improving the library. Hopefully users of the library will join in the discussion and suggest new features or improvements.
So, now perhaps is the time to look back, reflect and tell a little about the history of as3commons-bytecode :)
I started as3commons-bytecode after taking over the Loom project from Maxim Porges (http://code.google.com/p/loom-as3/). I had begun implementing an AOP solution for Spring Actionscript, first focusing on the pointcut scanning logic because I was following Maxim's progress with Loom and thought this would be an ideal library to use as its foundation.
Sadly, before the library was finished Maxim couldn't offer the personal resources anymore to continue the project. This certainly threw my schedule off :) At first I considered using the FLemit and FLoxy libraries but found that they were too specifically aimed at generating mocks. I need something more generic.
So that's when I started spelunking through the Loom code and step-by-step I actually started to understand what was going on. Before, I was very reluctant since I considered this stuff way beyond my mortal understanding. But I managed to fix some bugs and that's when I contacted Maxim and asked him if it was alright for me take over the project and bring it into the AS3Commons project.
Luckily Maxim was alright with this and so my nightmare begun haha :)
First thing I implemented was the bytecode based reflection. Since it appeared to be relatively simple and was a good way for me to get to know the code base a little. When this was done I started the task of finishing the parsing of all of the opcodes since this hadn't been completed yet. This was when the proverbial shit hit the fan because this is when I started to find out about subtle AVM documentation errors. Or just plain non-existent documentation...Luckily, a trip through the Tamarin source code offered quite a lot of valuable insight as well.
Actually getting the opcode parsing completely to work only got finished a few weeks ago :)
Next step was to generate classes at run-time. I was familiar enough with the ABC format by now to come up with an API to let a developer assemble an ABC file without needing to have any intimate knowledge of 'what lies beneath'. I actually used the .NET System.emit namespace as an inspiration.
Around the time that class generation was implemented, James Ward contacted Maxim Porges to see if he could persuade him to continue his work on Loom since James and Michael Labriola had been hacking away on a mechanism that could intercept SWF loading by the Flash Player.
An ideal hook for AOP and other black magic.
Maxim then forwarded James to me and afterwards Michael and James offered some invaluable help and advice in further developing as3commons-bytecode. Eventually this culminated in their Mixing Loom project (James' blog introduction) and their fantastic session called 'Planet of the AOPs' at the 360|Flex conference in Denver. This was the first true introduction of AOP to the Flash community I guess you could say.
After class generation was working the next step was to provide a generic API for generating dynamic run-time proxies. These are basically subclasses (generated at runtime) that incorporate an interception mechanism for methods and accessors (getters and setters). So when a method gets invoked on the dynamic subclass it will first invoke any registered interceptors, enabling these interceptor to perhaps change or replace the behavior of the underlying functionality. Most mocking libraries (like asmock, mockolate or mockito-flex) are based on this logic.
The API for this is explained in this documentation section on the as3commons site.
Naturally, the most interesting solution that can be created using this proxy API are AOP mechanisms and quite soon after the proxy API became available Marty Pitt went ahead and created Flapper. An AOP extension for the Parsley framework. As if this wasn't enough, he then also created another library called Dynamic Services, also a Parsley extension. This library is able to take an interface that describes a service class and generate this service on-the-fly. This can save you a lot of typing :)
David Arno discovered the library as well and went out to create AS3Introspection, a library that he himself dexcribes as "describeType on steroids". I think that pretty much covers it :)
Jeff Ardillo then went ahead and showcased a technique to create proxies without having to depend on the ProxyFactory to create them in his excellent blog article 'Aspect Oriented Programming in Flex'.
I am very excited to see all of these initiatives take shape as this is exactly the reason why I started as3commons-bytecode. It was its specific aim to be a foundational library and facilitate a platform for other developers to base their own solutions on. Seeing this actually taking place is very satisfying indeed, so kudos to all of you who have taken the library to its next level!
Lately the Flash/Flex twitter- and blogosphere has been buzzing a lot with all sorts of AOP solutions. The Swiz framework just announced their own AOP functionality in their upcoming version 2.0, for instance. This is all great news and opens up all sorts of new and exciting possibilities on the Flash platform.
In that spirit, expect to see a new As3Commons project to be released in the near future as well. It'll be called as3commons-aop and will offer a bunch of standard interfaces and API's that deal with advices and pointcut scanning. Hopefully this will help developers to easily incorporate AOP functionality in other frameworks out there. As we are used to eating our own dogfood, Spring Actionscript will naturally use as3commons-aop as its AOP foundation :)
Yet, I would like to stress, don't focus only on the AOP possibilities of as3commons-bytecode. I believe that projects like Marty Pitt's Dynamic Services show that much more can be achieved with the ability to generate classes at run-time. So be creative and try to come up with some more interesting solutions!
Thank you very much to everyone who has submitted bug reports, feature requests and developed solutions based as3commons-bytecode!
P.S. If you'd like to get involved with as3commons-bytecode's development or the as3commons project in general, please drop us a line! We always appreciate more help and contributions!
- ▼ September (3)