Three Dollar Quill

In this post:

• I got a late start again, and so it's short.
• I jump ahead to the "step function" idea, because the loosey-goosey way things are set up is just so draining to think about.

As I mentioned on Tuesday, I noticed that some of the functions making up the current version of Homunculus could quite easily be considered as methods of an object, rather than a long-running loop with locals. I started trying to write a replacement for the main function, and it's a little painful. I just feel like the code as presented in the tutorial has a "get things done quick, no matter the cost" feel, and that tends to obscure the code's motivation.

Okay, since the new code is currently dead anyway, let's see if I can represent the stuff in the main function as a bunch of logical steps. ... Okay, I was able to start on that, but it's hard to think about how to change the "action" stuff. Basically, mouse and keyboard input gets converted into "actions". Type-wise, these things are really weird to me, because the underlying data type is a dict that maps strings to arbitrary objects, but it's guaranteed that the current implementation will never produce a dict with more than one entry. It almost looks like I could replace them with a 2-tuple with a special do_nothing state. I might try that now, see if that makes me happier. Or I might not. It's kind of a half-measure, doing that, when what I really want is to make some namedtuple subclasses that contain behavior. Maybe the bahavior should be defined on the actions, which get passed the game object and mouse action, and process them? I think using polymorphism like that is ultimately the way to go. Per the single-responsibility principle, it means that changing the implementation of any action doesn't lead to a change in the step method, so it's better than what I have now, I think.

I've made the step function just act like that stuff is already in place.

I'm feeling good about taking these changes forward. I basically have three methods to implement now, and a bunch of classes to write. It's all the same amount of code, but now I can sort it into a bite-sized checklist. Divide and conquer, it's how we get anything done with this computer stuff.

Next week, I'll fill in as much as I can of the new methods and the action classes. Also, I want to write serializers for the new "game" class.