Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Getting rid of our "switch/case" crutch?!?

Wow, this whole Javascript thing is pretty powerful! I found this out there - waves his hand absently toward the interwebs - and thought it was a great read! <a href="http://encosia.com/first-class-functions-as-an-alternative-to-javascripts-switch-statement/" rel="nofollow">http://encosia.com/first-class-functions-as-an-alternative-to-javascripts-switch-statement/</a>
The assembly programmer in me shudders at the wasted cycles... but really, that can be said of all Javascript. That is a great example of the power of functional programming. Thanks, Lifer4700, I'll be sure to make use of this pattern in future scripts, where appropriate.
We should use this in Monster Mash John?
1385166960
Lithl
Pro
Sheet Author
API Scripter
John M. said: The assembly programmer in me shudders at the wasted cycles... It's a Lookup/Hashtable. Really, every JS object is like this. Hell, this is basically how Roll20's state object is designed to be used. This doesn't create "wasted" cycles, although it does use more memory. (Unless you've got thousands upon thousands of entries, though, the difference is insignificant.) The best way to use this design pattern is exactly as I mentioned in my first sentence: as a lookup, whether for data or for function definitions. I actually began writing a new script last night where the only feasible means of making the script work without access to the window object was to use this pattern.
1385170231

Edited 1385170422
You're absolutely right that it doesn't really matter in Javascript. Heck, for most cases its darn elegent. On a lower level though, and I imagine in the JS vm as well, every function call is going to have the overhead of prologues and epilogues as it builds up and tears down the stack segment. JS is probably optimized for this, though, and we're so far from the metal that it doesn't matter. I understand the value of the tradeoff here and its totally worth it for the task at hand and the language in use. Just a visceral reaction to the use of functions instead of a switc
1385189777
Lithl
Pro
Sheet Author
API Scripter
The lookup itself is merely storing references to the object content. Accessing the value in the lookup should be no different than accessing the value of a variable. Accessing a value in the lookup should be identical (or nearly so) to accessing two variables, actually -- lookup the lookup in the variables lookup, and then lookup the value in the lookup. Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo. If you're storing functions (anonymous or otherwise), then yeah you're going to be adding stack calls... once you call the function . (I'm ~80% positive that indexing into a JS object isn't like a C# class indexer, which is basically just syntactic sugar for a method call.) But that would be no different from calling a function from within the case statement, which would be the ideal code structure if the cases were long and complicated.