Static typing is a great thing. It makes a really good IDE support possible. It’s encourage you by developing, because your code is validated by compiler and you can write intuitive API’s.

But some times it is also cool to have dynamic typing.

AS3 is a very creative language also from this point of view. It let’s you extend code in many ways.
First and most convenient way is class inheritance. So you have a class A and it is extended by class B. Nothing special it is a rudimentary feature of an OO language.

Second and not convenient way of extending an instance of a class is to declare the class as dynamic (have a look at Object class).

package {
  import flash.display.Sprite;
  public class MyClass extends Sprite {
    public function MyClass() {
      var a : Object = new Object();
      a.element = 30;
      trace('a.element: ' + (a.element));
    }
  }
}

But you can also extend a class that is final or not dynamic in AS3, because AS3 is not only Class based OO language but also Prototype based. That’s how we can implement so called monkey patching.

package {
  import flash.display.Sprite;
  public class MonkeyPatch extends Sprite {
    public function MonkeyPatch() {
      Object.prototype.sayHello = function():void{trace("hello from " + this);};
      var myThis : * = this;
      myThis.sayHello();
      var s : Sprite = new Sprite();
      addChild(s);
      var myS : * = s;
      myS.sayHello();
    }
  }
}

When you declare a local variable in AS3 it turns out that it is visible for the hole scope it was declared in.
So for example you can declare a variable after its usage in code:

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
	public function Decl() {
	  trace(a);
	  var a : String = "hello";
	}
  }
}

But the assignment will be executed as “expected” after the trace and that’s why you see “null” traced in the console.

You can also make a duplicate declaration of a local variable, if it keeps the same type.

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
	public function Decl() {
  	  var a : String = "hello";
	  trace(a);
	  var a : String = "hello2";
	  trace(a);
	  // var a : int = 2; That would be bad!
	}
  }
}

Another interesting declaration behavior is the declaration of error variable in catch block:

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
	public function Decl() {
	  try{
		trace(a);
		a.length;
		// trace('error: ' + (error)); Invisible			
	  }catch(error:Error) {
		var a : String = "error";
		trace('a: ' + (a));
		trace('error: ' + (error));
	  }
	  trace(a);
	  // trace('error: ' + (error)); Invisible
	}
  }
}

So error is only visible in the catch scope but the catch scope is not really a scope because if we declare variable “a” in the scope itself it is visible in the whole method.

Last funny example is about for-loop and static initializer.

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
    static var array = [1,2];
    for (var i : int = 0;i < array.length;i++) {
      trace(array[i]);
    }
    public function Decl() {
      trace(i);
    }
  }
}

The problem with this code is that variable “i” is declared inside of class declaration and that means that it is a field. It also not declared with static modifier and that’s why you can’t use it in your static initializer code.

Economics of Terror:

Crack economics:

Motivation strategy for creative work:

Institutions vs. Collaboration

ActionScript3 does not support method overloading, but why do you want to overload methods?

In my opinion there are two answers:

1. You want to pass the same method different amount of parameters
2. You want to have methods with same name but different behavior

In first case AS3 provides you the feature of default parameter values:

function foo(var a : String, var i : int = 0): void{
  for(;i<=0 ; i++){
    trace(a);
  }
}

So you can call method foo with one parameter “foo(‘hello’)” or with two “foo(‘hello’, 2)”

Let’s talk about the second case: same name different behavior.

In this case you can use namespaces.

package my {
 
	public class NamespaceExamp {
 
		namespace NS1;
		namespace NS2;
 
		NS1 function foo() : void {
		}
		NS2 function foo() : void {
		}
	}
}

The interesting part of namespaces is also that those are not declaration but URI based (like in XML).

Have a look at this example:

package my {
 
	public class NamespaceExamp {
 
		namespace NS1 = "myNS";
		namespace NS2 = "myNS";
 
		NS1 function foo() : void {
		}
		NS2 function foo() : void {
		}
	}
}

In this case foo is a duplicate method and it doesn’t matter that we declared two namespaces, their URIs are same so both foo declarations are in the same namespace. BTW if you don’t declare URI explicitly as in the first namespace example than the runtime will generate a namespace by the location of declaration (complicated stuff).

Another interesting fact is that the keyword “public” is also a namespace, but with empty URI.

So this is also a duplicate declaration:

package my {
 
	public class NamespaceExamp {
 
		namespace NS1 = "";
 
		NS1 function foo() : void {
		}
		public function foo() : void {
		}
	}
}

ActionScript 3 has a keyword static that turns methods, fields, getter and setter into class members (not instance members).

It is a useful feature in languages as Java, where you have no top level functions and variables (btw. in JavaFX static is deprecated).

AS3 has both – static members and top level functions/variables (as JavaFX), so it is kind of an overkill in my opinion.

If you want to have a structural aggregation you can put all top level functions/variables in a special package.

For example there is a convention in CoreLibrary for constant carriers (have a look at the “StageAlign” class in “flash.display” package).

These carriers represent the possible input values for a property of a class. In the case of “StageAlign” it is the property “align” of the class “Stage”. (btw. FDT has a special auto completion for this conventional constant carriers)

It is possible to place all these constants in a package “flash.display.Stage” so you don’t have to write :

“StageAlign.LEFT” but just “ALIGN_LEFT” for example.