This will be around until the hosting runs out, which is about 5 days or so.

Look how Javascript/CSS3 has moved to the forefront, developers are implementing what flash could do a few years back, but are improving it with semantics and readability. Taking on some of the frailties of Flash (screen readability, fallbacks and other browser implementation issues), don’t get me wrong, it’s still not perfect, but it’s better than some of Flash’s attempts.

I know that there is only a limited amount of resources to implement some of the things developers want, but it seems that they’re not thinking about the broader picture. The company has spent quite a long time implementing the iOS packaging tool for Flash for example. It’s a great little tool, but probably underused considering it’s possible potential. Why do I talk about this, well it turns out that the way the packaging tool works is that it provides away to compile your ActionScript3 code via the LLVM into AVM code. It now turns from a JIT compiled language to AOT compiled language with some issues currently that you can’t have multiple swfs with code in them. This missed opportunity here is that LLVM can have many backend outputs, Adobe only implemented/used one backend and that’s targeting ARM (for iOS). It would be that much of a stretch of imagination to implement a different backend, C/C++/Java (the list continues). So instead of seeing ActionScript as a dead end language with no possible road a head long term (unlike haXe) there could have been a possibility where your ActionScript code could run natively on any platform with the speed of C/C++ (hand written code would obviously be much faster that this version, but it would be faster than running on the AVM!).

Imagine the possibilities, super fast code with the ease of developing with ActionScript… shame it’s never going to happen!

In all seriousness, I think the new 3D stuff is awesome, it’s going to be really amazing. If we can somehow utilise it for user interfaces then we’re off to a winner! That’s one of the major issues that I had and still have is that when it comes to rendering it just doesn’t cut the mustard. Hopefully this will change and it will give one less thing for me to bitch about. It’s sort of a love hate relation ship I have with the ecosystem that is Flash. One things for certain, I’m really thinking of leaving it and moving on to Java/Scala and even dare I say it Javascript (probably using haXe if anything)! Why I hear you cry, here be a list:

• ECMA 4 – I’m guessing Adobe are still in the spoils of the ECMA fallout, where Adobe aren’t 100% sure what to do. If that’s not the case, this is what is perceived from the dwindling hordes of developers. Is Adobe following ECMA Harmony or are they doing their own thing? The latest FP11 doesn’t look like it’s done any sort of move in any direction. The great rival that has appeared in the last couple of years (Javascript) seems to moving lightening fast, ok maybe they’re not all singing from the same hymn sheet, but at least they’re moving when it’s concerning the language (probably excluding MS here somewhat). Things that look appealing to me from a Javascript point of view or even original ECMA 4 document, which I believe should be in FP11. Even if there is no official ECMA 4 now, at least have the balls to follow it through!
  
  • Union types and the set of predefined union types
  • Type definitions
  • Subtypes
  • “like”
  • yield
  • let
  • Iterators
  • Map
• Enums – Why can ActionScript 3 not get enums, they’re basic simplicity that help reduce boiler plate.
• Abstract Classes – With all the functionality that ActionScript 3 is getting, it becomes a necessity to have more help from a language and I consider Abstract Classes part of that. Why can’t the compiler tell me I should override a class if I mark something as Abstract, hell it moans about something when I don’t override something which I should, it’s not like a massive leap?
• Private constructors – Why did we remove these again?
• Generics – Generics in ActionScript 3 is just decent, not good and not excellent, it’s just decent. It’s like they went, “we want to implement generics, but we don’t have the time. I know, lets implement it in a half arsed way!”
• Const – How about const keyword, is it implemented? Who knows? It’s not implemented in the Flash IDE, but is implemented the Flex SDK compiler, but you can create a swc file from the Flex SDK and use it in the Flash IDE? How have they managed to do this without changing the player or the Flash IDE? Well it turns out they only do a compile time (better than not I suppose!) and once the check is done, they use the var AVM2 Bytecode instead.
• Flex compiler – Why oh why is the Flex compiler aka mxmlc and compc two separate entities and why oh why do they not implement some really basic rules of optimisations.
  
  • Inlining
  • Constant propagation
  • Tail recursive optimistations

I really do hope this stuff is coming, because I think it really is make or break time. People that didn’t want to invest that much into Actionscript 3 are now moving or have moved on to other languages (Javascript). The people that are still riding it out for better language expressiveness to get down in code what’s on the tip of their fingers are thinking about it or have already done so!

Edit:
I was speaking with various colleagues about this thread and we all tended to agree, that most of this is syntax sugar. We use this language day in day out, I’ve invested a lot of time into this language and it would be helpful if this language could help us out as well.

You may as an observer say well this looks like language A or like B, I would love to work in A or B, but I’m on a project that requires AS3 and we don’t have to option to move to A or B. In the future though I think A or B is on the horizon, especially in these fast moving times.

• AS3-Actions – AS3 Actions is a beefed up undo manager
• AS3-Stream – AS3 Stream came about as the backing for AS3-Actions library to help with serialization, but has found it’s uses in other libraries
• AS3-Logger – Another logger! You have to make one, as no other logger does what you want!
• AS3-Transitions – The main aim of this library is that it’s simple and fast, use other Tween libraries if you want features!
• AS3-UISignals – AS3 UISignals is a library to help deal with the ever changing interfaces which we have to build for. This helps manage touch, mouse and gesture events for components
• AS3-UIComponents – This is the front face/GUI to UISignals, currently it’s in it’s early stages and is just a series of buttons, analog inputs
• AS3-Spod – The name is stolen from haXe, which is Simple Persistent Objects Database Library. The aim to help with SQLite databases. Because writing SQL is just plain boring!

I’ll be investing most of my time in the components and improving them

View the source code

I’m currently experimenting with the fusing of the DisplayList and the DOM and currently looks like I’ve got two approaches. More on this when I’ve got a solid test setup to verify this.

AS3-Mixins
I’ve been fortunate to have some free time recently (no idea how or where from!), but I’ve managed to get AS3-Mixins to a stable enough state so that it can be used without it break everywhere. There are a few notable improvements over the first initial creation of the project. It’s gone through a massive re-factor, with the aim to improve the speed of mixin creation at startup. Most of the work has also been looking into improving memory consumption and I spent a lot of time caching bytecode and types from flemit and the mixins project. There is still a bit to do in this area, but it’s a lot more efficient that it’s ever been.

I’ve also added the ability for method overloading from a super class, added the ability to use a mixin in a MixinFactoryPool and tons more. This was mainly aimed at the creation of say tiles in a game, so at the start of a level you can create a series of titles/enemies/etc and reuse them without worrying about how to store them or reuse them. It’s a strongly type factory so it knows what mixin belongs to which pools. There is even a debug helper class which you can use to find out how healthy the MixinFactoryPools are i.e. you can monitor how full the pools are and when they’re about to be grow because the pools will be exhausted. All very useful for development.

AS3-DOM
Another project I’ve started (told you I’ve got some spare time!) is the creation of a DOM system in AS3. With the aim to provide a very easy selection tool for user interfaces (or anything else you can thing of using it with). It’s basically in it’s infancy, but it’s going to be something like xpath for AS3. It’s not going to be the same as xpath, as I’ve not got the time nor the inclination to write every single xpath rule and it would take far too long and I’m sure you could get paid for doing that! One added bonus is that the xpath selection can actually work on the DisplayObject list. The down side is you have to convert the DisplayObject list to the DOM. I may look at away to make a better adapter for this, but for now a help function should suffice.

You can view all of this at my github repo

This is an example of how I would like my take of mixins to work in AS3. I’ve simply created a interface called IPosition, it will hold x and y positions.

1
2
3
4
5
6
7
8
9
10
11
12
13

package org.osflash.mixins.support
{
    public interface IPosition
    {
        function get x() : int;
 
        function set x(value : int) : void;
 
        function get y() : int;
 
        function set y(value : int) : void;
    }
}

Next we create an implementation that will for fill the interfaces.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package org.osflash.mixins.support.impl
{
    import org.osflash.mixins.support.IPosition;
    public final class PositionImpl implements IPosition
    {
        private var _x : int;
        private var _y : int;
        public function PositionImpl()
        {
            _x = 0;
            _y = 0;
        }
 
        public function get x() : int {    return _x; }
        public function set x(value : int) : void {    _x = value;    }
        public function get y() : int {    return _y; }
        public function set y(value : int) : void {    _y = value;    }
    }
}

Then finally we would need a implementation of the final subclass where all the mixins are provided. Notice I’ve also created a ISize, which is relatively the same as IPosition, but uses width and height rather than x and y.

1
2
3
4
5
6

package org.osflash.mixins.support
{
    public interface ISquare extends ISize, IPosition
    {
    }
}

I did a google search on traits and it sent me to a stackoverflow page, where Brian Heylin was asking the same question that I was thinking. This page lead to the working prototype he had created using AS Mock. In AS Mock it dynamically adds dependencies with alternative implementations, but it does this in a really clever way. Rather than overloading the prototype system, this injects bytecode at runtime. The great thing about doing this, is that you can design to interfaces, you get strong typing and most of all you get performance when the objects have been created.

So I created as3-mixins. It’s a separate project from the prototype because I wanted to be able to grow this into what I wanted. Get it whilst it’s hot, I’m going to working on a lot of things, but I’m currently looking at improving the performance of the creation of the bytecode at the moment. The project that actually handles the bytecode creation and runtime SWF generation is a project called flemit. I’ve only just started on refactoring this, but I’ve already started to rip out bits that are surplus to requirements. The end result might be that flemit gets consumed by as3-mixins. I’m hoping the two can be separate, but that depends if I make flemit so unusable to others that it actually makes no sense as another separate entity.

Hopefully I’m going to be able to work on this more, blog post about how the internals work. It’s actually relatively simple if a little long winded. And just so you know this is an example of how you would create a ISquare implementation.

1
2
3
4
5
6
7
8
9
10

var mixin : IMixin = new Mixin();
mixin.add(IPosition, PositionImpl);
mixin.add(ISize, SizeImpl);
mixin.define(ISquare);
mixin.generate().completedSignal.add(function(mixin:Mixin): void
                                        {
                                            var square : ISquare = mixin.create(ISquare);
                                            square.x = 5;
                                            trace("I have a square!");
                                        });

1. You know when something needs to listen to a Signal
2. You should know how many times your registering to said Signal

I’m more interested in number 2 for now. As the application is ironed out over time, it makes me wonder why we’ve got this extra functionality of allowing multiple listeners to registered to a Signal, when only one suffices. I’ve never been a fan of hooking on to direct callbacks, mainly for the reason that you don’t know what is coming through as the arguments and the added bonus of reading the documentation every time. I’m more interested in self documenting code, not that I’m against documentation! I just want to be able at a glance to understand what the code does (where possible of course).

I had thought about implementing a SingleSignal. The whole purpose of this is to provide away to have a one listener at a time callback. The SingleSignal had to satisfy the following:

1. Only register one listener at a time
2. Notify the developer if they tried to register more than one listener
3. Be faster than the default Signal, as we’ve not got the over head of the linked list and Dictionary
4. Use less memory than the default Signal

It didn’t take me long to implement the functionality of the SingleSignal, as I already had the excellent work of Robert Penner and Joa Ebert to start from. The current implementation is in my github repo. I’ve also created some unit tests to help improve the robustness and prevent errors slipping through.

The last thing I did was verify the performance using the existing performance testing in the repo. Here are the results from a release Flash Player (10.1r85.3) on a mac running 10.6.2:

AddOncePerformance
Note: All tests min time was 0ms for all.

	DeluxeSignal	Signal	SingleSignal
Frames per second (fps):	49fps	60fps	60fps
Memory used:	6mb	6mb	4mb
Max time:	8ms	7ms	4ms

RemovePerformance
Note: All tests ran at 60fps and the min time was 0ms for all.

	DeluxeSignal	Signal	SingleSignal
Memory used:	6mb	6mb	4mb
Max time:	6ms	6ms	4ms

There you have it. It’s up to 33% faster, which won’t be that noticiable, depends on how many addOnce or add and dispatches you’re doing. It also uses 2mb less, which is a good improvement overall. So if you know what the restrictions are of your application and you know you’re going to add one listener and you want to use less memory then a SingleSignal might be for you…

EDIT: slight refractor to make the article more concise.

So over Christmas I completely re-wrote the pureMVC into signalMVC which is nearly identical to pureMVC except for a few exceptions:

• Signal event bus – you make your interests in the mediator using IHooks, these are strongly typed classes.
• Removed singletons – these have become a big hinderance in the past. This has the consequence of removing the multicore code base.

You can view all the code here – https://github.com/stickupkid/ui-signals-mvc