So I promised in my [last post](https://www.mikecann.blog/programming/unity-ash-a-different-way-of-thinking-about-making-games-in-unity/) to show how how [Unity-Ash](https://github.com/mikecann/Unity-Ash) can make things easyier when it comes to Unit Testing.



I have added some tests to the [Unity Asteroids](https://github.com/mikecann/UnityAshteroids) example game. Lets take a look at one of the simpler systems as an example, the DeathThroesSystem:

[code lang="csharp"]
public class DeathThroesSystem : NodelessSystem<DeathThroes, Entity, Audio>
{
public DeathThroesSystem()
{
\_updateCallback = OnUpdate;
\_nodeAddedCallback = OnNodeAdded;
}

    private void OnNodeAdded(DeathThroes death, Entity entity, Audio audio)
    {
        audio.Play(death.deathSound);
    }

    private void OnUpdate(float delta, DeathThroes death, Entity entity, Audio audio)
    {
        death.countdown -= delta;
        if (death.countdown <= 0)
            entity.Destroy();
    }

}
[/code]

We can see its a really simple system that does a couple of things.

First we want to test that when a node is added to the system we play a sound effect. Using Unity-Test tools you can quickly whip up a test case:

[code lang="csharp"][testfixture]
public class DeathThroesSystemTests : UnityUnitTest
{
private IEngine \_engine;
private DeathThroesSystem \_system;

    [SetUp]
    public void Setup()
    {
        _system = new DeathThroesSystem();
        _engine = new Engine();
        _engine.AddSystem(_system, 0);
    }

    [Test]
    public void WhenANodeIsAdded_DeathSoundPlays()
    {
        var e = AddEntityToEngine();

        Assert.AreEqual(1, e.GetComponent<Audio>().toPlay.Count);
        Assert.AreEqual(e.GetComponent<DeathThroes>().deathSound, e.GetComponent<Audio>().toPlay[0]);
    }

    private GameObject AddEntityToEngine()
    {
        var obj = CreateGameObject();
        obj.AddComponent<DeathThroes>();
        obj.AddComponent<Audio>();
        obj.AddComponent<Entity>();
        _engine.AddEntity(obj.AddComponent<Entity>());
        return obj;
    }

}
[/code]

I wrote a little helper that adds an entity to the engine with the necessary components. In the future we could use reflection to looup the types on the Nodeless system, but for now its enough to satisfy the test:

![2015-11-02_17-28-19](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-02_17-28-19.png)

Next we want to check that after update the countdown is decremented.

[code lang="csharp"][test]
public void AfterUpdate_CountdownDecremented()
{
var e = AddEntityToEngine();

    var before = e.GetComponent<DeathThroes>().countdown;

    _engine.Update(1.5f);

    Assert.AreEqual(before - 1.5f, e.GetComponent<DeathThroes>().countdown, 0.01f);

}
[/code]

Easy, now we want to check that when the countdown is less than or equal to zero, the entity is destroyed:

[code lang="csharp"][test]
public void AfterCountdownTimerEnds_EntityDestroyed()
{
var e = AddEntityToEngine();

    var before = e.GetComponent<DeathThroes>().countdown;

    _engine.Update(before + 1);

    Assert.IsTrue(e.GetComponent<Entity>().IsDestroyed);

}
[/code]

Sweet and thats it! Sure we could add a few more tests for some of the corner cases but as an example I think it serves its purpose.

Let me know in the comments or email me: mike.cann@gmail.com with what you think!

[Over a year ago](https://www.mikecann.blog/portfolio/projects/unity-ashteroids-ash-framework-in-unity/) I decided to scratch an itch and see if I could get Richard Lord's Ash framework to work in Unity. It actually turned out to be far easier than I had imagined. A few people contacted me as they wanted to use it for production games so I decided to do [a little more work on it a few months later](https://www.mikecann.blog/programming/unity-ash-upgrades/) to fix some of the easily solved issues with my quick port.



Unfortunately I lacked any spare time to work on it until now. This week I spent 3 days rewriting the framework from scratch. I improved many things, making it much more Unity-friendly, and generally easier to use. Because of the differences from the AS3 version of Ash I now describe it as "heavily inspired" rather than a port.



Before I go into too much detail about the differences from [Richard's AS3 version](https://www.ashframework.org/) I should briefly explain Ash and how it differs and extends upon Unity's Enity / Component architecture.

## TL; DR

Checkout the Unity-Ash src: [https://github.com/mikecann/Unity-Ash](https://github.com/mikecann/Unity-Ash) and the example game: [https://github.com/mikecann/UnityAshteroids](https://github.com/mikecann/UnityAshteroids)

## Entity / Components in Unity

Unity is an Entity / Component game engine. This means that instead of having classes for object types such as Spaceship, Asteroid or Player which may extend some other classes you have Entities (Unity calls these GameObject's) which contain components that do the work.

![2015-10-30_09-48-45](https://www.mikecann.blog/wp-content/uploads/2015/10/2015-10-30_09-48-45.png)

This is a much better structure for game design as it favours composition over inheritance which prevents the common pitfall of the "[God Object](https://en.wikipedia.org/wiki/God_object)" when developing a game. By separating the concerns into differnt components you can reuse functionality by attaching components to Entities / GameObjects rather than extending a base class and overriding required functionality.

I won't go on any more about it, you can google the topic and find out plenty more.

## Entity / Components in Ash

Although Ash is an Entity / Component architecture, it differs quite fundamentally from Unity in how data and logic should be structured.

In Unity components typically extend MonoBehaviour and contain the variables and logic for that specific functionality. For example a simple Unity component may look something like:

[code lang="csharp"]
public class Bullet : MonoBehaviour
{
public float maxAge = 3;

    public float age;

    void Awake()
    {
    	age = 0;
    }

    void Update()
    {
    	age += Time.deltaTime;
    	if (age >= maxAge)
    		Destroy(gameObject);
    }

}
[/code]

Imagine that Bullet is a projectile fired from the player spaceship. We can see that the bullet ages over time and when it is equal or greater than the max age then it is removed from the game.

The Ash way of doing things is to separate the component data from its logic. So it may now look something like:

[code lang="csharp"]
public class Bullet : MonoBehaviour
{
public float maxAge = 3;
public float age;
}

public class BulletNode
{
public Entity Entity { get; set; }
public Bullet Bullet { get; set; }
}

public class BulletAgingSystem : ISystem
{
private INodeList<BulletNode> \_nodes;

    public void AddedToEngine(Engine engine)
    {
    	_nodes = engine.GetNodes<BulletNode>();
    }

    public void RemovedFromEngine(Engine engine)
    {
    	engine.ReleaseNodes(_nodes);
    }

    public void Update(float delta)
    {
    	foreach (var node in _nodes)
    	{
    		node.Bullet.age += delta;
    		if (node.Bullet.age >= node.Bullet.maxAge)
    			node.Entity.Destroy();
    	}
    }

}
[/code]

Here we can see that the Bullet's data is now separate from the logic which modifies that data. In Ash components should simple data, they can contain some methods but they should be limited to operating on the state of that instance, they certainty aren't allowed to have any dependencies on other components.

So instead of putting the logic with the data its been moved to a System. The system however may have dependencies on multiple components so it describes its dependencies by defining a structure, a "Node", in this case BulletNode. This class lists all the components an Entity must have before it can be used by the System.

What this means is that whenever an Entity (GameObject) is added or removed from the game the Ash Engine will automatically update the INodeList<BulletNode> with of all the Entities that match the required components specified in BulletNode.

If that all looks a little too verbose for you, one of the improvements I made in this rewrite of Unity-Ash was to provide a short-hand way of writing Systems in the form of the "NodelessSystem", so now the above example could look like:

[code lang="csharp"]
public class Bullet : MonoBehaviour
{
public float maxAge = 3;
public float age;
}

public class BulletAgingSystem : NodelessSystem<Bullet, Entity>
{
public BulletAgeSystem()
{
\_updateCallback = OnUpdate;
}

    private void OnUpdate(float delta, Bullet bullet, Entity entity)
    {
    	bullet.age += delta;
    	if (bullet.age >= bullet.maxAge)
    		entity.Destroy();
    }

}
[/code]

Now you may be thinking that's all well and good but it doesn't really improve things, you are just splitting the Monobehaviour up and adding more classes to the the game, which is true, but there are several benefits to working this way. One of those benefits becomes evident when you think about dependencies between components.

Suppose that we want to handle what happens when the player spaceship collides with an asteroid. We want to respawn the player somewhere but it would be a bit unfair if we respawned the player on top of an asteroid so we need to check that the new spawn location isn't too close to an Asteroid.

How would we go about this in Unity? Well one solution may look something like the following:

[code lang="csharp"]
public class Player : MonoBehaviour
{
private PlayerManager manager;

    void Awake()
    {
    	manager = FindObjectOfType<PlayerManager>();
    }

     void OnCollisionEnter2D(Collision2D coll)
     {
    	 var asteroid = hit.gameObject.GetComponent<Asteroid>();
         if (asteroid != null)
    	 	manager.PlayerHitByAsteroid(this);
     }

}

public class PlayerManager : MonoBehaviour
{
public void PlayerHitByAsteroid(Player player)
{
var asteroids = FindObjectsOfType<Asteroid>();

    	// Find a place to respawn the Player
    	var postion = UnityEngine.Random.insideUnitCircle*1000;
    	while (!IsClearToAddShip(position, asteroids))
    		postion = UnityEngine.Random.insideUnitCircle*1000;

    	player.transform.position.x = postion.x;
    	player.transform.position.y = postion.y;
    }

    private bool IsClearToAddShip(Vector2 newSpaceshipPosition, IEnumberable<Asteroid> asteroids)
    {
    	foreach (var asteroid in asteroids)
    		if (Vector2.Distance(asteroid.transform.position, newSpaceshipPosition) <= 1f)
    			return false;

    	return true;
    }

}
[/code]

Sure there are a few ways this could potentially be done but the point im trying to highlight is the way dependencies are handled in a typical Unity game. Usually we have managers which look after some part of the game and then we use FindObjectsOfType or Tags to get access to the entities in the system.

The ash way of doing it may looks something like:

[code lang="csharp"]
public class Player : MonoBehaviour
{
}

public class Collisions : MonoBehaviour
{
public List<Collision2D> hits = new List<Collision2D>();

    void OnCollisionEnter2D(Collision2D coll)
    {
    	hits.Add(coll);
    }

}

public class PlayerCollisionNode
{
public Player Player { get; set; }
public Collision Collision { get; set; }
public Transform Transform { get; set; }
}

public class AsteroidNode
{
public Asteroid Asteroid { get; set; }
public Transform Transform { get; set; }
}

public class PlayerCollisionSystem : ISystem
{
private INodeList<PlayerCollisionNode> \_players;
private INodeList<AsteroidNode> \_asteroids;

    public void AddedToEngine(Engine engine)
    {
    	_players = engine.GetNodes<PlayerCollisionNode>();
    	_asteroids = engine.GetNodes<AsteroidNode>();
    }

    public void RemovedFromEngine(Engine engine)
    {
    	engine.ReleaseNodes(_players);
    	engine.ReleaseNodes(_asteroids);
    }

    public void Update(float delta)
    {
    	foreach (var playerNode in _players)
    	{
    		foreach (var hit in playerNode.Collision.hits)
            {
    			var asteroid = hit.gameObject.GetComponent<Asteroid>();
                if (asteroid == null)
                    continue;

    			RespawnPlayer(playerNode);
    		}
    		_players.Collision.hits.Clear();
    	}
    }

    private void RespawnPlayer(PlayerCollisionNode node)
    {
    	var postion = UnityEngine.Random.insideUnitCircle*1000;
    	while (!IsClearToAddShip(position, asteroids))
    		postion = UnityEngine.Random.insideUnitCircle*1000;

    	node.Transform.position.x = postion.x;
    	node.Transform.position.y = postion.y;
    }

    private bool IsClearToAddShip(Vector2 newSpaceshipPosition)
    {
    	foreach (var asteroidNode in _asteroids)
    		if (Vector2.Distance(asteroidNode.Transform.position, newSpaceshipPosition) <= 1f)
    			return false;

    	return true;
    }

}
[/code]

Here we can see we have made the Collisions component generic so that it can be used by Asteroids, Bullets or whatever else requires collisions. Then we have a system that is specific to Player Collisions.

The PlayerCollisionSystem then gets references to the players and the asteroids and does the respawning logic.

Its important to realize that in Ash, Systems are not allowed to reference each other. They can only communicate by adding or removing entities / components or changing properties on those components. This may seem like a bit of a restriction at first but its really important to keep things separated and free from complex dependencies, as a side benefit it makes Unit Testing easier (more on that later).

## Single Point of Entry

So the final piece of the puzzle is how do these System's come together? What calls the AddedToEngine, RemovedFromEngine, and Update methods on the Systems?

Well this is another way that Ash differs from the typical Unity Game. Usually in a Unity MonoBehaviour you may add Awake() or Start() handlers which get triggered by Unity when the game starts up. The problem is that it makes it quite hard to know what order things are going to get initiated in. It also makes it really hard for a new coder to come to the project and understand how the project works.

In Ash you have a single entry point. So for example you may have something like:

[code lang="csharp"]
public class GameBoostrapper : MonoBehaviour
{
private EntityCreator creator;
private Engine engine;

    void Awake()
    {
    	creator = new EntityCreator();
    	engine = new Engine();

    	engine.AddSystem(new MenusSystem(), SystemPriorities.PreUpdate);
    	engine.AddSystem(new PlayerRespawningSystem(creator), SystemPriorities.PreUpdate);
    	engine.AddSystem(new LevelingSystem(creator), SystemPriorities.Update);
    	engine.AddSystem(new MotionControlSystem(), SystemPriorities.Update);
    	engine.AddSystem(new SpaceshipCollisionSystem(creator), SystemPriorities.ResolveCollisions);
    	engine.AddSystem(new HudSystem(), SystemPriorities.Animate);
    	engine.AddSystem(new AudioSystem(), SystemPriorities.Render);

    	creator.CreateGame();
    }

    void Update()
    {
    	engine.Update(Time.deltaTime);
    }

}  
[/code]

The Engine is the main control object for Ash. It holds a list of Systems which are updated each tick of the game.

The EntityCreator isn't an Ash specific class and is rather a helper class which is used to abstract out the creation of the entities from the business logic of the various systems (also important for the Unit Testing as we will see later).

There is one more piece I haven't mentioned yet. How is the Engine informed when Entities are added or removed from Unity? Well this is one of those places where Unity-Ash differs from AS3 Ash.

All GameObjects that should be picked up by the Ash Engine require that an "Entity" component be added to the GameObject:

![2015-10-30_11-57-09](https://www.mikecann.blog/wp-content/uploads/2015/10/2015-10-30_11-57-09.png)

The "Entity" represents an Entity in Ash but in Unity is actually a MonoBehaviour. It tells the Engine when the GameObject it is created and destroyed. One difference from my previous work on Ash is that if you want to add or remove components from a GameObject at runtime you should do it via the Entity directly so that it can inform the Engine:

[code lang="csharp"]
public interface IEntity
{
...
T Add<T>() where T : Component;
void Remove(Component component);
...
}
[/code]

This change was required to get around all the [performance problems related to checking for component changes each frame](https://www.mikecann.blog/programming/unity-ash-upgrades/).

## Unit Testing

Well this is another massive benefit to using Ash but this post is already way too long so ill save Unit Testing for the next part, stay tuned!

For now you can checkout Unity-Ash here: [https://github.com/mikecann/Unity-Ash](https://github.com/mikecann/Unity-Ash)

If you want to see an example of its usage you can see here: [https://github.com/mikecann/UnityAshteroids](https://github.com/mikecann/UnityAshteroids)

If you want some more info on Ash then you should check out the official Ash Framework site: [https://www.ashframework.org/](https://www.ashframework.org/)

Note its all still really new so things are probably going to be in flux quite a bit. I am really interested to get peoples opinions on this however. Let me know what you think!

[Last October](/posts/try-harder-2012-slides/) I was fortunate enough to attend the excellent [Try Harder](https://www.tryharder.org.uk/) conference for the second time.[ I have spoken before](/posts/try-harder-2012/) about how inspirational the event is where every attendant must give a talk on something they are passionate about. One of the talks was by David Wagner's and was on 'The Value of Tinkering' and it inspired me to[ tinker with TypeScript](/posts/tinkering-with-typescript/) which led to my [Recursive Chrome Extension](/posts/personal-project/recursive/).



Before I go any further I should mention that there is a [Try Harder 'Level Up'](https://www.tryharder.org.uk/level-up-2013/) session taking place in April that is open to new attendees, I thoroughly recommend you check it out!

Following on in the same 'Tinkering' vein I have decided to investigate an AS3 library by another Try Harder attendee [Richard Lord](https://www.richardlord.net/blog):

[![logo](/wp-content/uploads/2013/02/logo.png)](/posts/tinkering-with-ash/attachment/logo-4/)

What is Ash? Well direct from the [Ash Website:](https://www.ashframework.org/)

> Ash is a high-performance entity system framework for game development.
>
> An entity system is a way to organise the code for a game that is efficient for both code execution and code management. It uses composition rather than inheritance for sharing features between game objects and uses a data-oriented approach to separate the game state from the game logic. This makes it much easier to manage the code and to manage the game state.
> Im not going to go into the details too much of why composition over inheritance is a good idea as Richard has already done a much better job than I ever could in these two posts:

- [What is an entity system framework for game development?](https://www.richardlord.net/blog/what-is-an-entity-framework)
- [Why use an entity system framework for game development?](https://www.richardlord.net/blog/why-use-an-entity-framework)
  If you haven't got a clue what im talking about when I say Entity or Component I strongly recommend checking out his posts first.

The reason why Ash has piqued my interest is because for the last three years I have been working with Entity-Component systems for games but in a totally different way. The way I have been using and developing started with the Push Button Engine (PBE) method and later expanded out to include Dependency Injection culminating in the [Swft Framework](/posts/swft-dependency-injection-component-based-game-framework/).

Ill give one example of why am starting to fall in love with Ash:

In PBE and Swft the components contain data and functions. They can also declare dependencies (via [Inject]) which are automatically fulfilled when a component is added to an Entity. The functions in the component are able to act on their own data, other components and interact with the game as a whole.

One problem with this method is that components are largely tied to their entity and once attached aren't really free be removed or added. The reason is because other component may have dependencies that depend on that component being part of the Entity. Removing the component will cause the game to crash. This becomes a problem when you want to enable a certain chunk of functionality for a certain time then disable it, what you tend to end up doing is adding the component at Entity creation time then inside of it toggling its behaviour with a boolean.

In Ash components are pure data with the bulk of the functionality being contained within systems. Sure you can have functions in a component but they **only act on their own data**. There are no hard dependencies between components. What this means is that components are much more free to be added and removed from Entities. So how do component function together then? Well that's where Systems come in.

Systems are classes that contain the logic that makes up your game. When added to the engine they grab one or many lists of Nodes. A Node simply defines a collection of components that must exist on an Entity. In effect it declares the dependencies that this System needs to operate. What's neat about this is that this list of nodes is constantly changing as components are added and removed from entities. The Ash Engine manages this all for you so all the system need do is iterate over the linked list of Nodes each frame and execute its logic.

Systems also must not declare dependencies between each other. This rule means you don't end up with large dependency hierarchies between Systems. This frees up systems to be added and removed from the Engine with no side effects! This is rather remarkable as it lets you do crazy things that you couldn't normally do when there are many dependencies between systems. For example your game could have a Blitting based rendering system, then halfway through a running the game you could swap that out that System and replace it with a Starling based rendering System!

Thus far I have only spent a limited amount of time tinkering with Ash but I am having a whole lot of fun. I have started work on a little game to experiment around with the framework. At the same time I have been exploring [Starling](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CD8QFjAB&url=http%3A%2F%2Fgamua.com%2Fstarling%2F&ei=yiEdUazkL-uX0QWNz4EI&usg=AFQjCNHKL4BaeidkUlpmw48eBMwyhwG2tw&bvm=bv.42452523,d.d2k), the hardware accelerated 2D rendering framework built on Stage3D. Thus far I have produced this little map editor:

<object width="650" height="650" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="https://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="wmode" value="direct" /><param name="src" value="/projects/Mash/01/MashWeb.swf" /><param name="quality" value="high" /><param name="pluginspage" value="https://www.macromedia.com/go/getflashplayer" /><embed width="650" height="650" type="application/x-shockwave-flash" src="/projects/Mash/01/MashWeb.swf" wmode="direct" quality="high" pluginspage="https://www.macromedia.com/go/getflashplayer" /></object>
Click to place a block, shift and click to remove, scroll mouse to change block type and hold control and click to zoom in / out.

Its only a tech demo at the moment and as such hasnt got any game play elements. Im not entirely sure what to turn it into but as a platform for tinkering with Ash its been great.

Its too early to share the code at the moment but if you would like to see how some Ash code looks I strongly recommend you check out [Richard's Asteroids example on GitHub](https://github.com/richardlord/Asteroids). I was really quite taken aback by how neat and modular the code is. The example is provided in 4 different flavours, one using RobotLegs one with Starling one with SwiftSuspenders and one with no dependencies at all. The fact that the code still works and looks simple in all the examples really demonstrates the versatility of the framework :)

[![](/wp-content/uploads/2010/04/ScreenHunter_01-Apr.-08-20.11.gif "ScreenHunter_01 Apr. 08 20.11")](/wp-content/uploads/2010/04/ScreenHunter_01-Apr.-08-20.11.gif)

Twitter can be a funny beast, what makes it great can also make it poor. I use [Twhirl ](https://www.twhirl.org/)which keeps me updated any time one of the people I follow tweets about something, the only problem is that so many people tweet that if I dont happen to see it within about and hour or so of the Tweet, ill miss it. This time however I was lucky enough to catch a tweet by [@Joa](https://twitter.com/joa) about his new Inversion of Control and functional-programming-like library, [Funk AS3](https://code.google.com/p/funk-as3/).



As I have been getting well into [RobotLegs](https://www.robotlegs.org/) (a Dependency Injection MVCS framework) recently I was extremely interested to hear about this new project by Joa who I respect very much as a brilliant coder not least because of his excellent work on low-level Flash byte-code optimisation (see [Apparat](https://code.google.com/p/apparat/)).

Joa has taken a different approach to doing dependency injection. The approach most frequently used (and the one used in SwiftSuspenders / RobotLegs) is to use meta-data to declare to a number of variables for injection. You then map a class to be injected and instantiate it using the injector.

As an example, with Swift Suspenders you would define a class for injection with something like the following:

```

class MyInjectedClass
{
public function sayHello(toSay:String)
{
trace("Hello "+toStay);
}
}

var injector : Injector = new Injector();
injector.mapSingleton(MyInjectedClass);

```

Here we are telling the Injector to make a single instance of our class and hold it internally ready for when it is next requested, such as:

```

class MyDependantClass
{
	[Inject] public var myClass : MyInjectedClass;

	public function performAction()
	{
		myClass.sayHello("World");
	}
}

```

Here the [Inject] meta-data indicates that we want the framework to supply the class with an instance of type MyInjectedClass. The final part is to make an instance of the dendant class and inject into it:

```

var dependant : MyDependantClass = new MyDependantClass();
injector.injectInto(dependant);
dependant.performAction();

```

As you can see this is a nice way of handling inter-module dependencies in your code, when coupled with a MVC framework such as RobotLegs it becomes and extremely powerful yet elegant way of coding.

It however isnt perfect and Joa, on his [google code page](https://code.google.com/p/funk-as3/wiki/IoC) mentions three drawbacks of this method:

<blockquote>*   Your injected properties are publicly exposed and mutable.
*   describeType is very expensive.
*   Steep learning curve.
This is where he suggests his alternative method, which is quite ingenious. Using the same example as above you would see something like the following:

```

class MyInjectedClass
{
	public function sayHello(toSay:String)
	{
		trace("Hello "+toStay);
	}
}

bind(MyInjectedClass).asSingleton();

```

Then the dependant class would look like the following:

```

class MyInjectedClass
{
protected var myClass : MyInjectedClass = inject(MyInjectedClass);

    public function performAction()
    {
    	myClass.sayHello("World");
    }

}

```

And making an instance of it could be as simple as:

```

var dependant : MyDependantClass = new MyDependantClass();
dependant.performAction();

```

As can be seen there are some benefits to this method, the biggest one in my opinion is that injected properties dont have to be public as they are provided by the call from within the class scope rather than from outside.

So how does Joa perform this magic? By abusing a little used ability of the Actionscript programming language known as package-level-functions. These are throwbacks from the old AS1 &amp; AS2 days of global functions. There are actually a couple of common examples in AS3 still such as getTimer() and getQualifiedClassName() still used. What Joa has done is to use these package level functions as a method of generating concise looking code reminiscent of functional programming.

Performance wise, im not entirely sure whether by using package-level functions instead of describeType() calls used in meta-data driven IoC frameworks is any faster as Till Schneidereit of Swift Suspenders suggests:

> I don't think that Funk's approach is any faster than an optimized
>
> metadata-based IoC container: describeType may be slow (as in "takes a
>
> few dozen microseconds to run"), but is only ever called once for each
>
> class an instance of which is injected into. After that, it's just a
>
> straight iteration over an array for all injection points instead of
>
> Funk's multiple method calls for each injection point.
> So the next step for me is to run some tests to see how things pan out. Either way im very impressed with both approaches and cant wait to see what kind of exciting advances will be developed in the coming months.

Just as a follow up from my post [on the bleeding edge](https://www.mikecann.blog/programming/on-the-bleeding-edge/) I thought I would post a rather interesting image @srivello made and @jhooks shared. Its a relationship between the main components in the MVCS meta-framework in [RobotLegs](https://www.robotlegs.org). Its pretty good for anyone that (like me) preferrs to see a diagram when trying to grasp the concept of a new framework:



(click to enlarge)

[![](/wp-content/uploads/2010/03/ScreenHunter_01-Mar.-23-15.51.jpg "ScreenHunter_01 Mar. 23 15.51")](/wp-content/uploads/2010/03/ScreenHunter_01-Mar.-23-15.51.jpg)

[![](/wp-content/uploads/2010/02/ScreenHunter_01-Feb.-02-13.15.gif "ScreenHunter_01 Feb. 02 13.15")](/wp-content/uploads/2010/02/ScreenHunter_01-Feb.-02-13.15.gif)

Thought id mention these videos as I have been watching them and really like the content. They are a series of video blog posts by one of the 'celebrities' of the Flash and Flex world, in which he talks about lots of stuff related to whats going on in the industry and the various frameworks he uses or recommends (or doesnt). He also has a few things to say about beer, which is a bonus!



Anyways theres three of them so far, and can be watched over on his [blog](https://jessewarden.com/):

[1 vs Many, Mediator vs Presenter, 30 mins – JXLTV – Episode #1](https://)
[ Conferences, Why Frameworks, Cairngorm 3 – JXLTV – Episode #2](https://jessewarden.com/2010/01/conferences-why-frameworks-cairngorm-3-jxltv-episode-2.html)
[ Apple’s iPad, HTML5 Video, Gaia Flash Framework – JXLTV – Episode #3](https://jessewarden.com/2010/01/apples-ipad-html5-video-gaia-flash-framework-jxltv-episode-3.html)

[![ScreenHunter_01 Jan. 09 18.34](/wp-content/uploads/2010/01/ScreenHunter_01-Jan.-09-18.34.jpg "ScreenHunter_01 Jan. 09 18.34")](/wp-content/uploads/2010/01/ScreenHunter_01-Jan.-09-18.34.jpg)

Just did a quick update to the audio book organiser. Added the ability to move the storage database file. This was so that I can put my storage file on Dropbox and it will then be backedup and synced between machines.



New version and sources:

[airbadge]Audio Book Orgainser,https://www.mikecann.blog/flash/AudioBookOrganiser/AudioBookOrganiser.air,1,https://www.mikecann.blog/flash/AudioBookOrganiser/badgeImg.jpg[/airbadge]

Source: [https://www.mikecann.blog/flash/AudioBookOrganiser/AudioBookOrganiser_v120_source.zip](https://www.mikecann.blog/flash/AudioBookOrganiser/AudioBookOrganiser_v120_source.zip)

Well its been a fun Christmas, I have eaten and drunk to the point that im going to be running it off in the gym till next christmas.

Although there has been merryment abound, the keyboard couldn't keep me away. Its probably okay to say this now as im not under any secrecy act; I have decided to leave Massively Multimedia in Manchester to join a new startup called Ideas Pad in Wilmslow (just south of Manchester).



I cant say too much about exactly what I will be working on just yet but I can say that it will involve my experience in the Flash world. Specifically, I will be working in Adobe Flex again on some fairly sizeable projects. For this reason I wanted to brush up on my Flex as there has been a new release of the IDE (now named Flash Builder) and the SDK.

In addition I wanted to look at the various frameworks in use for Flex these days. I have used the usual Cairngorm, PureMVC before however I stumbled accross a new one called Mate (pronounced mah-tay, like the drink). Mate looked very interesting to me so before I jumped two feet in and used it in a commercial project I wanted to give it a spin in a simple project first.

Finally we get to the point of this post. I have developed a simple Adobe AIR application that allows you to organise audio books. The basic idea is simple you give the application a selection of 'source' directories where your audiobooks belong then you can tick off whether you have listened to each one, and what rating you would give them.

[![ScreenHunter_02 Dec. 30 12.32](https://www.mikecann.blog/wp-content/uploads/2009/12/ScreenHunter_02-Dec.-30-12.32-300x262.jpg "ScreenHunter_02 Dec. 30 12.32")](/wp-content/uploads/2009/12/ScreenHunter_02-Dec.-30-12.32.jpg)[![ScreenHunter_03 Dec. 30 12.32](https://www.mikecann.blog/wp-content/uploads/2009/12/ScreenHunter_03-Dec.-30-12.32-300x261.jpg "ScreenHunter_03 Dec. 30 12.32")](/wp-content/uploads/2009/12/ScreenHunter_03-Dec.-30-12.32.jpg)

The data is persisted to a file that is saved to your hard drive, so when you open the application up again next time it remembers which audio books you have listened to and what ratings you gave them.

I havent tested it very much atall so there is a very high likelyhood of being some strange bugs in there. I am also releasing all the source code for this project for all to see, use and study if they so wish.

[https://www.mikecann.blog/flash/AudioBookOrganiser/AudioBookOrganiser.air](https://www.mikecann.blog/flash/AudioBookOrganiser/AudioBookOrganiser.air)

Source: [https://www.mikecann.blog/flash/AudioBookOrganiser/AudioBookOrganiser_v101_source.zip](https://www.mikecann.blog/flash/AudioBookOrganiser/AudioBookOrganiser_v101_source.zip)