Loom and Swiz

[maxim.porges]

Copying in discussion with Chris Scott.


================

From: chris.s...@gmail.com
Subject: loom
Date: February 15, 2009 12:19:29 PM EST
To: maxim....@gmail.com

Hey man,

When are you gonna get some loom onto gcode? Is there any way I can
get an early access zip, maybe with a quick example? I'm working on
aop for swiz this weekend, and I think loom has to be the way to go.
I'd also like to talk to you about plans. My two cents is, it would be
awesome to have a library like cglib, and then a reflection library on
top of it, both of which I could use in swiz. I know you want to do an
aop framework too. I think it would be cool if they were all
independent small libraries, but I have no idea how you are putting
things together.

Let me know when you are around,

-C

[maxim.porges]

From: Maxim
Subject: Re: loom
Date: February 15, 2009 12:42:45 PM EST
To: Chris

Hey Chris,

Thanks for touching base. I'm not going to make the library public
until you can construct a runnable proxy from a class definition,
which I'm currently working on. That being said, I'm going to work
with you and the guy behind mock-as3 privately so Loom will support
your projects.

The first iteration of Loom is finished, and can parse and process
bytecode directly from ABC files compiled with asc, and then write
them back out again unmodified. You can use it to read class
definitions and run a modified version of abcdump that I wrote to
trace out the class structure.

The second iteration is in progress, which will allow you to define
classes on the fly and run a bytecode generator that reads the dynamic
class definitions and makes AVM-compliant ABC files as output. The new
code will ultimately replace the old code, which was just a bridge to
get to where I am now. The objects in the new code will also be the
reflection API.

I can definitely get you an early-access release.

Cheers,

- max

On Feb 19, 9:36 am, "maxim.porges" <maxim.por...@gmail.com> wrote:
> Copying in discussion with Chris Scott.
>
> ================
>

[maxim.porges]

On Feb 15, 2009, at 12:57 PM, Chris Scott wrote:

Hey hey,

I took a look through asmock (http://sourceforge.net/projects/asmock/)
this morning, is that the same as mock-as3, Richard Szalay? He has a
whole heap of reflection, class definition, and proxy classes, but I
have not tried to see what his proxy factory actually creates. If Loom
becomes the underlying bytecode / reflection library for both
projects, that would be amazing.

I have a really good start to Swiz's AOP, the internal structure to
run interceptors and match them against a method object work great.
I'm going to keep expanding the Poincut model untill you can match not
only class / methods, but also runtime arguments. Will be really
sweet. I've started working on processing Aspects to construct advice
and interceptors, it's going to be much different than ColdSpring, way
less configuration, all autoproxy. Should be crazy simple to use.

After that, it would be awesome if we can sync up for constructing the
proxies. Let's decide a time when we can have a connect review, and
hopefully I can show you the AOP goodness too. One thing I was
thinking of today. In flex it's pretty standard, and Swiz encourages,
using bindable public properties on objects, which you may want to
proxy. In order to handle that transparently, we would need to
override accessors, and make them bindable. Actually, we'll need to
preserve bindable wherever we find it.

Talk to you when you have time, Chris

[maxim.porges]

Hey Chris,

> I took a look through asmock (http://sourceforge.net/projects/asmock/)
> this morning, is that the same as mock-as3, Richard Szalay?

No, mock-as3 is a mocking library along the lines of JMock, whereas
asmock is record-and-playback. Brian LeGros sent me a link to asmock
the other day, since it has a bytecode weaving library in it called
flemit. I looked through asmock and flemit, and the mocking and
bytecode generation parts are currently coupled, although Richard
mentioned on his site that he intends to split them apart after he
gets the mocking finished.

Richard has done a nice job with both libaries. It was kind of funny
looking through flemit since the domain classes are really similar to
Loom's (which is unsurprising since they both map the AVM2 spec).
However, the generation approach is different.

flemit/asmock's approach is:

1) List the classes you want to generate mocks for
2) Use describeType() to introspect them
3) Create class definitions from describeType's XML definitions,
replacing the opcodes with the mocking instructions
4) Write to bytecode
5) SWF-load the bytecode
6) Run the unit tests

Loom's approach is:

1) SWF-load, introspecting the ABC bytecode at load-time
2) Weave proxy subclasses based upon metadata tags in the original SWF
3) Run code
4) Advise at runtime

Advice can be added to Loom's proxies as you see fit on a per-
instance basis, since the advice will just be method closures.
Obviously, you'd use a factory to add the same advice over and over.
You could also weave opcodes during step 2 if you want to (which I
plan on having support for since it's what I'll to generate the
proxies), but then you have to understand AVM opcodes in depth, which
most people won't. I want people to be able to use Loom without
understanding the AVM, so the runtime proxy is the way to go. I also
plan to have a describeType()-based runtime loader/adapter, but it's
not my first priority since I already have an ABC parser.

> ... In order to handle that transparently, we would need to

> override accessors, and make them bindable. Actually, we'll need to
> preserve bindable wherever we find it.

Properties are different beasts than other slot traits in the ABC
bytecode, so we can differentiate them and handle them however we
want. I believe that the Flex compiler expands Bindable metadata in to
code, so we should get all the bindable stuff for free; you'd just
proceed a method invocation to the bound properties in the superclass
after applying advice. Worst case, we can write opcodes to do whatever
we want - you just write the code in Flex, use my abcdump utility to
get the opcodes, and use them as a template, then use Loom's API to
inject the opcodes during the load-and-weave step.

- max