Eventually I managed to trick ASDoc into completing, but it has opened up further cans of worms. There are a whole bunch of practices in the JASPA code base that the AS3 compiler really doesn’t like. I’ve tried to be strict, but apparently not strict enough. In some cases I feel that AS3 is just being unreasonable, for example, you cannot have private constructors in AS3. A common practice for singleton classes is many OOP languages.

Here’s another example, where an extended event class provides access to an extended target -

public class EventTarget {
}

public class Event {
    public function get target():EventTarget;
}

public class SpecialEventTarget extends EventTarget {
}

public class SpecialEvent extends Event { 
    override public function get target():SpecialEventTarget;
}

The overridden getter that returns a sub-type of the target is considered invalid. I don’t see how this is bad practice. Surely a more specific type of event should be allowed to return a more specific type of target, especially as the extended target still has all the traits of the original target.

Of course you can always cast with the as operator:

mySpecialEvent.target as SpecialEventTarget;

The question is, do I really want JASPA to be tied so closely to AS3? At the end of the day it is a separate language, and is designed for compiling into JavaScript not for emulating ActionScript.

I am not caught between two options.
1. Alter the JASPA codebase to be even more like AS3
2. Write a JAS documentor, jasdoc

What do you think?

I effectively gave up Flash when I came to Public and it’s now a whole year since I did any significant Flash work. In this short time AS3 has really come of age, there are tonnes of serious libraries, from fractals to physics, and PaperVision 3D seems almost omnipresent. The prospect of going back to the ActionScript freelance circuit after a year on the wagon would be quite daunting.

The reasons I’ve done little Flash since I’ve been at Public are perfectly sound: I work with two brilliant Flash developers who make up 50% of our development team, and rather than everyone doing a bit of everything, we all specialize quite specifically. I cover all the back end work, and do a lot of server admin; so ActionScript in my personal world is now just a fond legacy of my freelance career.

ActionScript is still of great interest to me – JASPA is closely modelled on AS3, and at Public Flash makes up the majority of our projects, so I obviously stay up to date on its progress. But I’ve spent so many hours writing ActionScript that it seems a shame I won’t be so directly involved in its future. I started using Flash in version 3 and so I’ve seen ActionScript develop from nothing in real time. I remember when Flash 5 came out and we could finally write real code. I made a concious decision there and then to ditch Lingo, because it was starting to become obvious that Flash had a brighter future on the web. This turned out to be a very good decision.

As usual with my blog posts I feel I need to write some kind of conclusion (recalls GCSE English lessons), but I don’t have one; except I miss Flash, it’s awesome. The end.

Sadly the people I feel need to appreciate his point the most probably won’t get past the second paragraph. That point, or at least the one I took away from it, is best summarized by this quote:

“[...] as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.”

Bang on. Except, maybe not harder, but just less likely. In the [invariably rapid] world of creative web development this is known as “getting shit done”. Young developers in my business don’t learn JavaScript; they learn jQuery. They don’t learn PHP, they learn [ahem] WordPress. (as if PHP wasn’t already a high level abstraction). Now don’t get me wrong! I’m not pleased about this, but there is a happy medium to be found somewhere, and I don’t believe we’ve all settled on it yet.

Joel is pretty hard on the idea that abstraction saves us time, and seems to argue that on balance the time saved working is still spent learning. Maybe this is true of people who do the learning, but many do not. And sometimes it just isn’t practical. The ActionScript world seems to be dominated at the moment by PaperVision 3D. Obviously you should have buttoned up your AS3 before diving into a library like this, but as for a solid understanding of the 3D engine; what are you going to do? Pop out for a quick doctorate in 3D mathematics in your lunch break? There is not doubt that this huge abstraction empowers many developers with some real might, with some very real time saving.

I have always maintained that the more you understand about what lies beneath the abstraction layer in which you are working the better you will be at your job. Would you train someone on Dreamweaver, before they proved they could write HTML? However, there is a balance to be found that works for you and your business. Web development would be impossible without the many layers that exist between the code in an HTML page and the OS of the server dishing it up. As the web evolves more layers tend to get added, and nowadays popular code libraries are adding layers within layers.

At the bare minimum you have this: (please excuse rudimentary linear format, and refrain from posting flowcharts)
HTML < Browser < HTTP < Server

Then we add a wizzy AJAX front end and some back end architecture:
JavaScript < HTML < Browser < HTTP < Server < PHP < MySQL

Then we use some cool 3rd party libraries to save us some work:
jQuery plugins < jQuery < JavaScript < HTML < Browser < HTTP < Server < Drupal modules < Drupal < PHP < MySQL

The more layers, the more points for possible failure. If you only have knowledge (i.e. control) of one or two of these points you are in a weaker position when things go wrong. If you have knowledge of all these layers you are in a much stronger position to harness the value of the extra layers, rather than suffer from them. This kind of philosophy is rarely evaluated when people make business decisions off the back of a Drupal press-release, but it’s one that I ensure I keep an eye on, especially when recruiting.

This area is of particular interest to me at the moment, so expect more posts on the topic.

Unlike JavaScript and AS2, AS3 supports method closures implicitly; so I made sure they were built into the JAS language. Such a thing is not native to JavaScript so the JASPA compiler automatically generates a call to helper function jaspa.closure whenever an object’s method is referenced.

If you’ve ever used Delegate.create in AS2, then you’ve encountered this issue. If you don’t see the problem, consider this example in JavaScript:

1. var Cat = function(){
2.      this.voice = ‘Miaow’;
3. }
4. Cat.prototype.speak = function(){
5.      alert( this.voice );
6. }
7.  
8. var Sammy = new Cat;
9. Sammy.speak(); // alerts “Miaow”
10.  
11. var Callback = Sammy.speak;
12. Callback(); // alerts undefined

As soon as we’ve created a reference to the function member, we’ve severed it from its owner, so when we call it, it’s not being called on the object. In JavaScript and AS2 we need to use a method like Delegate.create to explicitly create a closure. Here’s an example:

1. function makeClosure( obj, func ){
2.      var closure = function(){
3.          return func.apply( obj, arguments );
4.      }
5.      closure.apply = function( obj, args ){
6.          return func.apply( obj, args );
7.      }
8.      closure.call = function( obj ){
9.             var args = [];
10.              for( var i = 1; i < arguments.length; i++ ){
11.                  args.push( arguments[i] );
12.              }
13.             return func.apply( obj, args );
14.      }
15.      return closure;
16. }

It’s basically a wrapper function which seals in the original arguments. Additionally apply and call must be overridden or calling them directly will spoil the party. Try it with the Cat example and you’ll see the desired result.

1. var Callback = makeClosure( Sammy, Sammy.speak );
2. Callback(); // alerts “Miaow”

Not only are the standards fairly brief, but they contain errors. I’ve not managed to find an official errata, so here’s my starter for 10.

1.3.1 Variable Length Unsigned 29-bit Integer Encoding (U29)

The standard states that the largest unsigned integer permitted is pow(2,29)-1, which would be 0x1FFFFFFF, but then goes on to state that the range of a 4 byte value goes up to 0x3FFFFFFF. This looks like a typo, unless I am missing something critical!

The AMF standard is supposed to be platform independent [ish], so it doesn’t talk about Flash [much]; but it’s worth noting that the Flash Player uses U29 for serializing signed integers, making its useful range -0x10000000 -> 0x0FFFFFFF. Flash serializes all integers outside this range as a doubles, even when the AS type is uint; because the AMF protocol does not support an unsigned data type.

I find this data type a bit pointless. It is designed cut down on redundancy, but surely this could be achieved with different integer markers, 8-bit, 16-bit, etc.. The range of the integer wouldn’t have to be restricted and it would probably deserialize faster too.

1.3.2 Strings and UTF-8

There appears to be a typo in the third paragraph which contradicts the grammar notation below. It states that a zero flag indicates a string literal, although it says below that a zero value indicates a reference. The latter seems correct and is the same convention used in other parts of the standard.

More to come …

So in this spirit of pedanticalness I’ve been playing around with the various changes to the null, and undefined types in AS3 and how they relate to the new concept of untyped objects. Having been writing JavaScript and ActionScript for years these notions are taking some getting used to. That’s fine, but I have noticed some nuances that I’m not happy with.

I’m fine with the notion that a typed object cannot contain the value undefined. It makes sense that it should adopt a native value of its own. I do find it strange though that a Number defaults to NaN, whereas int, and uint default to 0, but I think I’ll just about sleep at night.

I also find it odd that some typed objects may be set to null, while some cannot. (var s:String = null;) holds null and is still a String, and yet: (var n:Number = null;) raises an error. Although I don’t really get this, being aware of it is the important thing when it comes to avoiding bugs.

Here are some more weird things I discovered today:
Setting a Number to null via a function call prevents the error you get when setting it directly.

1. function getNull():* { 
2.     return null; 
3. } 
4. trace( getNull() === null); // prints ”true” 
5. var x:Number = null; // raises error 
6. var y:Number = getNull(); // no error   

Setting a Number to undefined via a void function call raises an error

1. function getUndefined():void{ 
2.     // no return value. 
3. } 
4. trace( getUndefined() === undefined ); // prints ”true” 
5. var x:Number = undefined; // sets to NaN as expected 
6. var n:Number = getUndefined(); // raises error, halts execution

Hmm..

The South Park Chin balls Flash app required that the user drag and zoom a loaded photo. Anyone who’s ever done this will know that you can’t just scale the picture around it’s registration point when you zoom. Why? because the centre point changes as you pan the image around. So the requirement in a nutshell is – to be able to scale a MovieClip around an arbitrary centre.

Sure, you could take the Russian doll approach with multiple clips inside clips, but that just ain’t cool! I thought I’d share the way I did it as it’s pretty concise.

First of all here’s the principal in action. Scaling and rotation, both performed around an arbitrary centre point that you can alter by dragging that little marker around. Go on, have a go.

[ Update: due to a nasty server crash some of these files are missing.. sorry. This source was rescued though ]

Loading example SWF…

Download the source files for this example

Most of the source files just serve to create the example interface. The only class we need to discuss is the one with the scale and rotating logic. The class VirtualCentreSprite is an extension of the Sprite class. In AS2 it would have to be an extension of the MovieClip class, but we don’t need a timeline. You could use this as a base class for sprites across your project to ensure they all have this capability.

It has two methods as follows:

void scaleAround( offsetX:Number, offsetY:Number, absScaleX:Number, absScaleY:Number )
void rotateAround( offsetX:Number, offsetY:Number, toDegrees:Number )

The scaling method is the simplest. It’s basically GCSE vector maths. We calculate the position that the clip should be at after scaling, do the scaling (which will move the clip according to the centre that Flash knows about) and then we simply reposition it to where it should be.
Click to see source of method scaleAround

The rotating method is a bit more complex, because it uses a transformation matrix. But thanks to the flash.geom package this is short and sweet. Again the principal is that we let Flash rotate the sprite and then adjust the position.
Click to see source of method rotateAround

I was quick to upgrade to AS2 when it came out in Flash MX 2004, and never looked back, so why so late? Well, as usual, because I’m busy. Busy on a PHP project at that, so I haven’t really had the chance. Plus, if I do have to write some AS on the job it’s too big a risk to start learning something new. Pressures demand that I get on with it as I know how. That’s why this Facebook application has it’s main Flash app (Chin Balls) written in AS2. Also, I view the upgrading of a programming language as a one-way process. I didn’t upgrade to PHP5 until I was confident I would never have to write PHP4 again. And with AS3 this is an even bigger deal.

I anticipated that AS3 was going to be stricter, less forgiving, and that I’d have to get used to a few things, but I have to confess to being quite surprised at how different it is. There’s so much material on AS3 available to you that there’s no point me banging on about things you can get better information on else where. However, as an AS2 developer here’s a quick list in no particular order of the things that either surprised or pleased me in my first couple of hours of AS3 writing:

• The MovieClip’s inheritance chain has 5 other classes between itself and the Object class. This abstracts out various types of functionality and means you don’t have to use a fully loaded MovieClip just to display a blob.
• Small, but caught me out – Void must be lower case as a return type, e.g. function():void{ } My bad.
• Watch out; Ctrl-t only checks syntax.
  This is more profound than it sounds. I suspect the reason that AS2 compiles the script and checks all references and types is because that’s the best chance you’ve got of catching an error. AS3 actually has the ability to do this at run time, so don’t think “This script contains no errors” means you’re in the clear!
• At last; percentage properties like alpha are now 0-1, instead of 0-100. Another design interface legacy bites the dust. – and say goodbye to underscores in property names too :)
• A new override keyword must be used to redefine a parent class method of the same name
• MovieClips do not have implicit onEnterFrame, onRelease, or any such handlers invoked by default. You have to explicitly define all event handling via the thoroughly standardized Event mechanism.
• Looking for onLoad? You won’t find it, see above;
• Declaring child clips as member variables in classes was raising conflicts with members of the same name placed physically on the stage. It took me a while to find the publish setting “Automatically declare stage instances”. If you’re used to declaring all your physical members switch this off. If you’re normally lazy, switch it on!
• No more prototype hacking. Not even if it’s 10pm and you really want to go home.

The casual and flexible nature of ActionScript has lent itself very well to the creative industries in particular over the years. In short, it gets the job done! And unfortunately that’s what this business is all about most of the time. But ActionScript has really grown up this time. Of course you can still publish Flash movies in AS2, and even AS1, but if you want to grow up too you’re going to have to get a bit more serious – again. This means more planning and less hacking. Generally you are going to spend longer doing pretty much everything.

I know plenty of creative developers who have been writing ActionScript for years and many of them eventually embraced AS2, even if a little reluctantly. AS2 was an important step in the maturing of the language, but a step that was in fact a bit of an illusion. The structure and strictness that it appears to impose is really rather superficial and the list of hacks and compiler workarounds is endless. Under the hood AS2 is pretty much the same deal as AS1. i.e. it’s JavaScript. JavaScript was purposefully designed for non-programmers. How often have you done this to create a button action:

myBtn.onRelease = function(){ /* do stuff */ }

What you are doing is creating a function object and assigning it as a property of another object. You can do this because the prototype architecture of JavaScript allows you to – a concept foreign to pretty much all class-based languages.
Well you can’t do it any more. – not in AS3.

This time around Adobe has based the language on the draft specification of ECMAScript Edition 4 (ES4). AS1 & 2 (along with most implementations of JavaScript that you’ll encounter) are based on ES3 which is nearly ten years old now. So under the hood AS3 is genuinely a different beast and a more grown up one at that.

So with the ever-stricter, and more robust stature of ActionScript, how long can this designer/developer melting pot survive? And how narrow can the margin remain between the developer and the designer? I don’t mean to suggest that designers can’t code or that coders can’t design, but there are only so many hours in the day, and only so much you can fit into one person’s job description. Perhaps the distinction of merely two roles isn’t sufficient anymore. We don’t talk about Flash development in terms of front and back ends, but perhaps we should. As the gap widens perhaps we can identify multiple roles for specialists across multiple layers of development just as we do with HTML based web apps.