var/this VS. var/that[]

ID:154258
 
Feb 27 2002, 2:19 pm
After having a hayday fiddling with this[] and that[]'s, I'm starting to wonder what the point of having normal "var/this = 0" variables is at all? Using the []'s format (whatever you call it) allows for variables that don't even need to be defined, anywhere you want you can just use if(this["Whatever variable you make up"]) and it'll work just fine, although it defaults to 0. Just set the same made up variable to 1 somewhere and poof, whole new variable!

But, is this too simple to be correct? It seems it's so easy to use, there must be SOME bad side effect to it. So, any experts on this out there, fill me in, would you?
Feb 27 2002, 9:28 pm
I think the code

if (this["Whatever variable you make up"])

says the var named this is a list and you want to know if the value associated with "Whatever variable you make up" is true.

The downside of always using lists is that you could hit the limit of 65535 lists at a time rather quickly. Using "normal" vars will avoid taking from your list resources.
Feb 28 2002, 4:29 am
Foomer wrote:
After having a hayday fiddling with this[] and that[]'s, I'm starting to wonder what the point of having normal "var/this = 0" variables is at all? Using the []'s format (whatever you call it) allows for variables that don't even need to be defined, anywhere you want you can just use if(this["Whatever variable you make up"]) and it'll work just fine, although it defaults to 0. Just set the same made up variable to 1 somewhere and poof, whole new variable!

But, is this too simple to be correct? It seems it's so easy to use, there must be SOME bad side effect to it. So, any experts on this out there, fill me in, would you?

I'm not entirely clear on what you mean here. Are you asking why we should define specific vars instead of using associative lists for everything?

Associative lists are great, but they're not a catch-all. By using them for all or most of your vars, you'll have a few problems:

  • Specifying the wrong string (or other "key") will cause strange, difficult-to-diagnose bugs by essentially splitting one variable into two; inconsistency is a killer.
  • List associations have no type. You have to explicitly cast every value to an /obj or some other type any time you want to access its procs or vars.
  • Code is less space-efficient, and less readable. myvarlist["x"] is a lot longer than just x.
  • Bugs that would have been caught by the compiler are caught at runtime instead.
  • Program speed is drastically reduced because of the overhead of looking up items from a list.

    Associative lists are wonderful, but they have their place. Using them for all vars is akin to using goto for all loops, but worse. What you'd essentially be doing would be taking one of the simplest language constructs and replacing it with one of the most complex.

    Lummox JR
Feb 28 2002, 9:56 am
In response to Lummox JR
  • Program speed is drastically reduced because of the overhead of looking up items from a list.

    Not drastically. There was a discussion not too long ago where we found out that associated values are stored in a binary tree, which means lookup is rather fast.
    Getting a value from a plain variable is one operation.
    Getting a value from an associated list, at worst case (when it's the alphabetically last associated value), takes 2 * log2(number_of_associate_values) operations, plus one to get it from memory. Here, log2 represents a logarithm with base 2. (I think these values are right, the 2* I'm not too sure of.. anyway, regular lookup is O(1) while associated lookup is O(log n), which are quite comparable with small numbers).

    -AbyssDragon
Feb 28 2002, 9:59 am
In response to ACWraith
The downside of always using lists is that you could hit the limit of 65535 lists at a time rather quickly. Using "normal" vars will avoid taking from your list resources.


I hope Dantom vaporizes that tiny limit sometime soon...
Feb 28 2002, 10:02 am
In response to AbyssDragon
AbyssDragon wrote:
  • Program speed is drastically reduced because of the overhead of looking up items from a list.
    Not drastically. There was a discussion not too long ago where we found out that associated values are stored in a binary tree, which means lookup is rather fast.
    Getting a value from a plain variable is one operation.
    Getting a value from an associated list, at worst case (when it's the alphabetically last associated value), takes 2 * log2(number_of_associate_values) operations, plus one to get it from memory. Here, log2 represents a logarithm with base 2. (I think these values are right, the 2* I'm not too sure of.. anyway, regular lookup is O(1) while associated lookup is O(log n), which are quite comparable with small numbers).

    But compare O(1) with O(log n) and you get the idea: If n is even a moderately-sized number, then every variable lookup takes several times as long (because the equation is a lot closer to k*log(n)+2); and variable access is at the heart of every single program. Furthermore, in this situation type casting is often required--or worse, the dreaded : operator (which doesn't like lists, BTW)--so program speed goes down the toilet in a huge way. Thus an associative list should be used only for situations where it actually makes sense, which is still many. Vars are so important to the overall language structure that replacing them with a vastly more complex construct without cause is a bad idea.

    Lummox JR