For reasons best ignored I recently investigated the different ways in which static initialisation code can be run in Flex. As well as a direct equivalent to the static initialiser blocks available in Java and C#, Flex has a couple of subtle variants that can prove useful in different circumstances.
First up, the "standard" static initialisation technique, the direct equivalent to that found in Java and C#. The block of code shown below will execute once, the first time an instance of
MyClass is created before that first constructor call is executed.
If the intention of your code block is to create and initialise a static variable then this approach is clear and obvious. However, if you want to run some general initialisation code you still require a dummy variable and a return type on the static function. This is because the variable initialisation is the hook required to execute the function. This technique was used throughout the Flex 3 Framework code for style initialisation on components (an approach no longer in Flex 4 because of the improvements to style initialisation).
The second technique is that used by the Automation framework that is included with the SDK. This approach allows code to be executed when an application or module is loaded. The code would look as follows:
root argument will be an ISystemManager or IFlexModuleFactory instance depending on whether the class was loaded as part of an application or module. Note that for the
[Mixin] to be picked up the class must be included in the application or module, i.e. it must be referenced elsewhere in code or explicitly added using appropriate compiler arguments
The final technique comes from ActionScript's ECMAScript heritage, in particular its prototype-based object model. In this case, code is written directly into the
class scope, i.e. not inside a
function block. This code will be executed the first time the class is executed in any way. That is, if the class uses the
[Mixin] technique then it will execute along with the mix-ins
static init function, otherwise it will be the equivalent to the "standard" approach and execute the first time the class is instantiated.
I know it looks odd, but it genuinely is valid!
So putting it all together in the most artificial of examples, the following class would produce the trace output 1, 2, 3, 4 (with 3 and 4 only appearing when an instance of the class is instantiated):