View Full Version : VAR vs. CONST
ad.sign
September 22nd, 2008, 09:56 AM
Ok, here goes the first prompt: consts are expired at the end of functions?
And the second one: what's the real advantage of using it instead of vars?
jwopitz
September 22nd, 2008, 10:36 AM
So say you have a custom event class and you have a const MY_CONST. Any attempt to change this at run time will result in a run time error saying you can't. The idea of a const is that its value remains CONSTANT through out the life span of your particular session. Const values are assigned at compile time and cannot be changed afterwards.
Vars are most always dynamic, meaning they are assigned at compile time and/or run time.
Use const if you want to persist a value of some kind thru out the life of the application. Otherwise stick to vars.
jwopitz
September 22nd, 2008, 10:40 AM
I forgot to put this in context, sorry. When making this comparison, generally it is thought of at the class level. So:
static public var changeMe:String = "will throw no errors during run time if you change me"
static public const DONT_CHANGE_ME:String = "...lest you want a run time error"
wvxvw
September 22nd, 2008, 11:21 AM
>> Ok, here goes the first prompt: consts are expired at the end of functions?
Constant declared within the function will expire after the function returns. But, they may be also useful within the function, especially if you are using the same number / string repeatedly many times. You would probably want to use it when optimizing bitmap operations / another long parsing / rendering routines... (they are not faster, it's just to make sure you don't overwrite the original value).
ad.sign
September 22nd, 2008, 01:57 PM
Actually I would like to know what should be better (var or const) in cases like this:
public class Warehouse
{
/**
* @return The item ID.
*/
public function newItem(item:*):uint
{
const ID:uint = storeItem(item);
private1(ID, foo1);
private2(ID, foo2);
return ID;
}
}
When we talk about consts, almost all the times we remember of classes and its constants. Like we usually do for many purposes. But my question's scope is minor, i think... inside methods, for example, I could use const instead of var to create unchangeable stuff.
It is not something consistent... since one's calling from outside the class could change the ID afterwards.. but is somewhat clearer to code.
So there is the reason for my 2 first questions... again:
1) At the end of the newItem method... would 'consts' expire like 'vars' does?
2) Is there any performance issues or any other issue to think about in that case?
Tanks very much.
wvxvw
September 22nd, 2008, 03:04 PM
No, actually not much, primitive types are copied into another function by value, so making it const or var wouldn't change anything. And, non-primitive constants just don't make sense, you can modify the content anyway.
I don't think there may be any performance issues (tested it on few different things, and it gives the same results as var), and yes, the constant is discarded after the function returns.
Constants would make much more sense if you ware able to determine whether you are working with hub memory, or stack memory, but, as long as Flash never uses hub, constants are much the same as variables...
JonnyR
September 22nd, 2008, 04:32 PM
I find constants are more appropriate at Class definition level for replacing static member variables which replace magic numbers / strings (http://www.google.co.uk/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMagic_n umber_(programming)&ei=0wDYSMuCDYie1waF1oC7Dg&usg=AFQjCNEBrhFvMq4tSp1fmTLhIkLF2eIkMw&sig2=rtQBgjzZXmOgqdUitmScWw) in your code.
ad.sign
September 22nd, 2008, 05:11 PM
Tanks! ;)
Powered by vBulletin® Version 4.1.10 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.