↓ Archives ↓

The fussy type

Recently I have been creating a lot more libraries for the flash player that rely on reflection, dawn being one of those.  I found that my reflection requirements where not easily met with the current tools, and so, Fussy was born!

Love it or hate it describeType is the only (almost) way to preform reflection on types in actionscript, it returns a XML document containing information about a type in one big dump! There are a number of excellent and proven libraries out their that can convert that XML dump into a nice OO data structure for you to code against, and it crossed my mind several times while developing dawn that they could make my life a lot easier. I however, created another reflection library… what was I thinking!?

Thing is, I have never needed a full strongly typed objected orientated representation of my type! That would be nice of course, but when I turn to reflection its not to create Method and Parameter objects (I’d rather the runtime did that to be honest) its because there are specific things about a type that I need to find.

A simple example of what I need reflection for in dawn would be to find all the methods in a type that have been decorated with the [Inject] metadata and have one or more arguments. i.e. all the injectable methods for a Class. Whether the reflection API gives me a XML document or the same information parsed into types I’m still going to have develop a way of finding all the methods with Inject metadata. Maybe that will be with e4x or maybe a loop over some objects (perhaps ensuring that they are methods not variables/accessors), then I will need to check that those methods have some arguments and are thus injectable. So whatever the means the types reflection information is provided by, the actual logic of my task is entirely up to me to develop and test.

With all that in mind, I built Fussy to be a little different from current reflection libraries (at least those that I know of). I wanted something to help me query my types, where the query represented whatever I wanted to find out about my types. To show you what I mean by “query”, lets see how fussy allows me to find the injectable methods on a type (the problem from above)

Start by creating a fussy

var fussy:Fussy = new Fussy()

Now to describe my query

var query:IQuery = fussy.query().findMethods().withMetadata("Inject").withArguments();

Now I can execute that query against any type, and get a array of strongly types Method objects

var methods:Array = query.forType(MyClass);

And TA DA! I have strongly typed method objects that satisfy my query for MyClass.

So what is Fussy?

Seems quite late in this post to be asking that, but I figured it would be easier to explain after an example. I call fussy an actionscript reflection query language. It does of course perform reflection, and parse the result of that reflection into strongly typed objects (only after a query has run) but the main aim of fussy was to make the logic of reflection (the reason why I was reflecting in the first place) easier as faster.

Fussy is a work in progress, I still think I can make the query API more elegant and there are lots more query extensions I can think of to add but its already pretty useful. It now supplies dawn with all its reflection needs, and what was a huge proportion of dawns code (searching and parsing types) base has been reduced down to one class.

Got lots more plans for Fussy, including things like metadata schema validation.  I find its pretty useful, so figured someone else might too.

Oh, here is the github link :)

6 Comments

  • May 12th 201013:05
    by Jos

    Reply

    Without really knowing what i’m asking, is it possible to pull out the query language into its own Interface, and allow the use of different reflection libs? I’m thinking that ppl sometimes are attached to their own reflection stuff, but if the query “part” could be separated out, it might allow for more Reflection libs to support that part of it.

    I don’t know if what i’m asking is crazy-talk or not however, and it could just be coffee speaking.

    Looking forward to spending some time looking at this! Thanks for sharing!

    jos

    • May 16th 201014:05
      by sammy

      Reply

      Hello there jos,

      That is an interesting idea. I believe it would be technically possible, but I think perhaps a more useful way to work with other reflection libraries would be to re-implement the IResultParsers (converts XML into strongly typed objects) to return Method, Variable, Metadata objects etc for other libraries. Then fussy could replace the implementation of the reflection libs in your code without affecting code that expect the objects generated by them.

  • May 12th 201014:05
    by J.

    Reply

    I just read your article, and don’t test your Fussy, but it seems kick ass !! Really good !

  • May 15th 201017:05
    by Mark

    Reply

    Very nice library! Works very intuitive.

    Would it be an idea to quickly filter out metadata tags somehow? something like this:

    fussy.query().getTypeQuery().forType(type).metadata.get(“Remote”); // returns Metadata with remote

    fussy.query().findProperties().withMetadata(“DataMember”).forType(type).metadata.get(“DataMember”);

    This concept could also be applied on the properties list of the metadata.

  • May 17th 201019:05
    by Mike cann

    Reply

    Very interesting!

    Remind be of the FunkAS3 Lib by Joa: http://code.google.com/p/funk-as3/

    Seems like functional programming is slipping out of the realms of Haskel more and more these days :p

    Mike

  • May 18th 201000:05
    by Josh McDonald

    Reply

    Hey, @darscan sent me a link to this, nice work. I’ve been rejigging my own reflection lib so it was very timely. I’m a big fan of fluent API design, but your idea of building the query first and then execute it against a class later is quite unique.

  • Leave a Reply