Static public constant ActionScript 3 good practices

Question

I don't know excatly how the static public constants work in ActionScript 3.

Does the constant value will be calculated every time I use it?

Here an example :

public static const DIAMETER:Number = 100;

Then if I set this constant like this

public static const RADIUS:Number = DIAMETER /2;

I don't know if the result will be calculated every time I use this constant.

I need some informations about it.

Same question with a constant object type:

public static const MY_POINT:Point = new Point(100,100);

Thanks ;)

Answer 1

A 'constant' (const) is an object that can only be set once and must be set in close proximity (generally immediately) to the declaration of the object. So you can't do this:

const val:String;

... 5 minutes later ...

val = 'hello world'

Instead, you must do:

const val:String = 'hello world';

From the docs, it appears you can set it later than this, but there does not seem to be a predefined time or order in which you can set it. You are best off setting it immediately as I did above. If you compile in "strict mode", it must be set as I did above.

A constant is good for process time. Because it is a fixed value, the runtime can store it differently and in a much more efficient manner. I cannot remember specifics, but consts offer substantial improvements in object-access-time over a standard variable.

static is an access modifier, just as private or public are (there quite a few others and I suggest you read up on all of them). Static objects exist only once. A standard object is declared every single time its class is instantiated/accessed. A static object is only declared the very first time. So consider the following

public class ClassA {
    public static var URL:String = "http://google.com";
    public function ClassA(){
        //hello world
    }
}

That is a simple class with a public static var stored in it. When I instantiate the class as so:

var hello:ClassA = new ClassA();

URL is created and set to Google's URL. Now, a static property does not belong to an object, so if you attempt to access hello.URL, it will fail. Instead, it belongs to the class definition. So you access it as ClassA.URL. Within ClassA's scope, you can access it via ClassA.URL or just through URL. Generally, static objects are used in two places:

1. Util classes. Math.PI or Math.max() are good examples of this
2. Objects where you need to save a single instance. I like to use them for User systems where you have the ability to sign in as a single user only at any given time. I generally have a User object where I store username and accountType and the like.

A static object is both good and bad. For a Class that will be instantiated a thousand times and the value will never change, it offers a substantial memory usage benefit (instead of storing 15 bytes x 1000, or 1.5 kilobytes, you only store the first 15 bytes). However, there are scope issues and general OOP standards to consider. You will find people who will argue until they are blue in the face that static objects, and by association Singletons (read up on those, they are not the same as a static object), should never be used because it goes against OOP principles. My example of using it for a User object is debatable if it should be static or not. Some would argue it should be a Singleton (my latest project used a Singleton instead, actually) and some would argue it should use other methods, some would even argue the User object should be passed infinitely through objects so it arrives where it needs to (which is an absolute nightmare to deal with).

In reality, use them as you see fit. You are the developer. Figure out what works best for the project and for you and your team.

Read here about constants and here for a good general overview about access modifiers in AS3 (and most class-based OOP languages in general)

A static const offers benefits from both. It is an object that only exists once and is only set once, so it offers memory AND process time benefits. It is generally used when you need to save a value that will never change but needs to be accessed multiple times (like Math.PI or MouseEvent.MOUSE_DOWN)

Answer 2

const

A constant is constant. That means it does not change, because it is constant. The idea behind a constant is that you can be assured its value does not change during runtime. If you try to assign a new value to a constant, you will get an error like this:

1049: Illegal assignment to a variable specified as constant.

In your example, RADIUS is not re-calculated. In fact, that behaviour doesn't occur when you access any variable - unless you are accessing it via a getter that needs to calculate the result before returning it. An example of this might be a getter that returns the distance between two points.

In your final example, you are assigning a Point to a constant. This behaves a little differently than you might expect. What you cannot do is go ahead and assign a new Point to the MY_POINT. What you can do however is modify the values of that Point. For example, you will be able to do this:

MY_POINT.x = 10;

Constants are best suited for storing primitive types (int, uint, Number, Boolean, String). In this case you would be better off creating separate constants to store the x and y of your Point, and omit creation of a Point:

const POINT_X:int = 10;
const POINT_Y:int = 15;

static

The static modifier is actually not related to constants, it is a separate keyword that adds the property or method being defined to the class definition rather than instances of that class. Because a constant is stateful and does not change, there is no reason to have a constant attached to every instance of a class.

Constants are useful for adding readability and security when working with primitive data. Those constants can be stored as static members of a class acting as a collection of related constants, or a class that makes use of those constants as arguments of its methods.

The Event class is a good example of this - it stores primitve data (strings) as static constants to represent the different event types, e.g. Event.ACTIVATE. When using methods that expect an event type, e.g. addEventListener(), we can refer to that constant rather than the primitive "activate". This protects us against bugs, because the primitive allows spelling errors - if you make a typo accessing a constant, you will receive a compile-time error.