PDA

View Full Version : public const or public static const


cpucpu
03-18-2010, 06:46 PM
I have seen this several times.
As those contatants are public and for its nature are not going to change, people often makes them static, i don't know if this is for some kind of conveninece or for what.

The difference lies in it's implementation.

/*where MyClassA has a property: public const A_CONSTANT:uint = "someString";
and a method simpleTrace(string){trace(string);}*/
import MyClassA;

private var _myObjectA = new MyClassA();
_myObjectA.simpleTrace(_myObjectA.A_CONSTANT);


Agaisnt

/*where MyClassA has a property: public static const A_CONSTANT:uint = "someString";
and a method simpleTrace(string){trace(string);}*/
import MyClassA;

private var _myObjectA = new MyClassA();
_myObjectA.simpleTrace(MyClassA.A_CONSTANT);

ASWC
03-18-2010, 07:46 PM
there's a purpose to that. Static variables belong to the class while member variables belong to the instance of the class. A public static const is therefore very different than a public const since a public const can be set in the constructor and so be different for each instances.

cpucpu
03-18-2010, 08:02 PM
I never thought in this, good point.

wvxvw
03-18-2010, 09:14 PM
ASWC:
How'd you set a constant in constructor?

ASWC
03-18-2010, 09:39 PM
ASWC:
How'd you set a constant in constructor?I thought I remembered it was possible. I guess I'm confusing with another language or I was just confused. So forget anything I said there's no difference between static and non static const then.

cpucpu
03-19-2010, 12:25 AM
Ok, well then, may be that's just not as.

Flash Gordon
03-19-2010, 12:59 AM
don't know what you are trying to say, but if it's a constant it's already pretty much static to the class. public constants should be static. private....eh. whatever.

ASWC
03-19-2010, 12:10 PM
public constants should be staticOf course since public const can't be set in constructor they are no use as member variables. But now I wonder, where did I get the const can be set in constructor? It has to exist in other languages right? Or am I dreaming altogether? :confused:

wvxvw
03-19-2010, 12:51 PM
Well, I think it's OK to have both static and instance constants. However the latter is seldom needed. Besides, to be honest, constants in AS3 are somewhat of a gimmick... Normally, you'd expect the compiler to be able to replace the call to a constant by it's value. But AS3 compilers don't do that. So, in terms of performance, using literal constants such as strings and numbers is better (however, error-prone).

ASWC
03-19-2010, 12:57 PM
if I'm creating 1000 instances I would also be creating 1000 public const member variables holding the same value so why not just go with only one static? Or am I missing something?

wvxvw
03-19-2010, 07:28 PM
Well, there is a difference between theory and practice. The theory suggests that constants should be simple types and shouldn't be modifiable. (Thus having a constant of complex type is not entirely correct). But, if you will have a constant of the complex type, say array, as an instance field, then every instance will receive a new array (not a reference to one array).

ASWC
03-19-2010, 07:52 PM
that makes sense. So then we are back to having a point on having public const member variable. Only problem of course is that having this const complex object only makes sense if the instances can modify this object state which it can of course but then why having this complex object as a const? I guess my lack of B.S starts to show here ...

wvxvw
03-20-2010, 07:49 PM
Well, to be honest, I cannot think of a situation, when this feature would be useful...

cpucpu
04-12-2010, 07:11 AM
A bit old thread but i found a use case for static over non-static.
If you need to initialize a constructor with a constant of the object itselft you can't, cause the const you need will only be availabe after object construction, therefore this won't work:
_miClass= new MiClass(_miClass.SOME_CONSTANT);

You need this instead:
_miClass= new MiClass(MiClass.SOME_CONSTANT);

Just for the record.

maskedMan
04-12-2010, 02:55 PM
Well, there is a difference between theory and practice. The theory suggests that constants should be simple types and shouldn't be modifiable.

This just reminded me of a use I sometimes have for constants that does involve a "complex" type.


private static const POINT:Point = new Point(0,0);


If you find that you might have to instantiate many points (in a loop, every frame, or similar), you'll call the new operator a great many times... but often you don't really need a new literal point... just some point with the correct x/y location. Calling a private static const has been a bit less intensive when called hundreds of times compared to hundreds of point instantiations.

spooner
04-12-2010, 04:10 PM
If you are making a public const, it should be static.. I can't think of a reason not to. The public vs private question though has more to do with purpose of the variable.

MichaelxxOA
04-14-2010, 03:26 PM
Wouldn't it be the same as static vs. non-static anything?

If it's a public static const then that means that it's being used in places other than the class that defines it. If it's not static then it's only being used in the class that defines it. Same logic should go into deciding which to use as well. ie: Should you expose that static const thereby creating a dependency between the class that uses it and the class that defines it?

I haven't looked at the bytecode generated when a const is used, but they are supposed to inline the value at compile time ... but ActionScript could handle that differently.

wvxvw
04-16-2010, 10:38 PM
I haven't looked at the bytecode generated when a const is used, but they are supposed to inline the value at compile time ... but ActionScript could handle that differently.
Nope, AS3 Adobe compilers have no concept of inlining - constants in the compiled code are references. In cases like events it makes them twice more expensive to use than their literal values. I.e. the constant would compile to:
getlex "flash.events.Event"
getproperty "COMPLETE"
vs
pushstring "complete"

This just reminded me of a use I sometimes have for constants that does involve a "complex" type.

In your case than I wouldn't make it static, instance field access is faster. Or, at least the access of the instance field has constant time, while static will be slower the more fields there are.

MichaelxxOA
04-19-2010, 03:28 AM
Thanks wvxvw

mindprism
09-13-2010, 11:03 AM
But now I wonder, where did I get the const can be set in constructor?


I think your thinking of a readonly member in C#.

drkstr
09-19-2010, 01:39 AM
It's called coding convention people! Use it. Love it.

public static const MY_CONST:String = "foo";

Could you do it differently? Sure.

...But should you?

;)

Triynko
03-05-2012, 08:55 PM
If the constant is public (implies class-external access), use "public const", because it provides faster external access, even though it may require more memory as it's stored per-instance rather than per-class.

If the constant is private (implies class-internal access), use "private static const", since it will save memory, and can be accessed from within the class at about the same speed as the non-static version.

In generally, accessing "static" variables and functions in ActionScript from outside the class's own code is very slow. How slow? Running a simple for loop shows that accessing a "public const" is about seven (7) times faster than accessing a "public static const".