This is the simplest version that I could come up with which works in the greatest variety of cases. If you knew that you were only going to use it with integer arguments, then you could create a faster method to generate keys than converting the arguments to strings and combining them with join.
In case that it isn't clear, memoization only helps if you are calling the memoized function many times with the exact same arguments. Otherwise, it will be slower, due to the overhead of creating the keys and storing the result, and it will be a waste of memory. It is a very nice alternative to creating explicit lookup tables, because you are creating the table on the fly instead of beforehand. If you decide later that you would prefer for the computations to be done beforehand, you can simple call the memoized function sooner and let it cache the results.
If you have a different version of this technique, please post it to the comments area.
]]>I have been using this new mode for a couple months and I haven't had any problems, but your coding style might differ from mine, so please let me know if you run into any issues.
Update: Here is the other set of functions that I use when I code actionscript. As I said before, you probably will want to just pick and choose some functions from this file since it is highly customized to my personal environment and has a lot of dependencies.
]]>As a supplement to that set, I also recommend the XV Series. This set isn't geared towards games, but it contains a lot of foley sounds that aren't in the other set.
]]>For more info on why free software matters, please visit The Free Software Foundation.
If you'd like to test drive GNU/Linux, you can burn a copy of Knoppix. With Knoppix in your cd or dvd drive, you can boot into a fully functioning GNU/Linux distro without putting anything on your hard disk.
*I'm sure that I will still be using Flash for client projects in the foreseeable future.
]]>Now, I have created a new variable that points to the constructor function. By calling Initialize(), I can re-run the constructor without having to create a new instance. As long as all the member variables are initialized in the constructor, the object should be good as new.
This solution works best if you can maintain a pool of instances, and grab a free instance when you need it. For my firework project, I create around 200 sparks up front because I know that is the maximum that I will ever use at one time. Then, instead of creating and deleting sparks during the game, I just borrow them from the pool and return them when I'm done.
]]>Below is a simple utility class, Hook.as, that provides two functions for working with hooks. The first function returns a new function that can be used to add hooks to an event. The second one returns a function that will run all the hooks that have been added.
The second class, Simple_Button.as, is something that I use in a lot of places to give button behaviors to MovieClips. It uses the functions in Hooks.as to create hooks for button events and for disabling/enabling the button. For a button press event, I might add one hook to change the button graphic and a second hook to do whatever action the button should perform.
Here is some example code that I used to create three buttons for selecting a character in a game:
This might seem convoluted at first, but the best part is that everything only does one thing. One of the main goals of functional programming is that there are (nearly) no side-effects. Notice that there's no "owner" or "parent" crap in any of the buttons. Also, notice that "buttons" is a local variable, but all the functions that you create with MakePressButtonFunc will always keep a reference to it, even when it passes out of scope. That's the "closure" that Actionscript and Lisp can do that many languages can't. Lisp advocates think that it's one of Lisp's most important features.
I'm not sure about the implementation in Flash, but in Lisp there are not any performance issues with creating all those functions, because it isn't like creating a new object. The "new" functions are actually very similar to the methods of a class. That's why you don't have to say "var f = new function." Also, the closures have those passed-in variables bound to them, so they might even be faster than "owner.doSomething()" which has to look up "owner" and then call the function.
Anyway, for me, this stuff has solved a lot of problems that I've dealt with in the past and I've been able to reduce a lot of my code significantly.
]]>This code was built off of some example code by Patrick May. Dave Roberts, on the sbcl-help mailing list also gave me a few pointers.
This server probably doesn't need to be multithreaded if you are only using it to catch your debug output. I, however, plan to build some other servers off of this, so I am keeping it this way.
The necessary Actionscript to communicate with this server is the same as the Python version.
The Heap class that I wrote is an implementation of the Heap functions from the book "Introduction to Algorithms," by Cormen, Leiserson, and Rivest. I made some changes to make it work in Actionscript, and I implemented the key function in an iterative, rather than recursive, control structure (as was suggested in one of the exercises), because it runs a lot faster in Flash (about 30-60% faster on my machine).
Note that I also use the cpp preprocessor with my code, which I described in this post. If you aren't using a preprocessor, then you need to inline the macros Left, Right, and Parent. It should be trivial in this case, because they are only used a few times.