Planning is slowly coming to a close now that I’m down to API specification. Slower than I’d hoped. But I’m still managing to solve important problems so I don’t feel too terrible about the rate of progress.<\/p>\n
Programming strategies are a funny thing. For any given established design technique it’s not very hard to find a counter argument against it. Which\u00a0isn’t really surprising, when you get down to it there’s no single perfect piece of code for any sufficiently complex problem. The best you can do is optimize for the specific angles that are most important for your project.\u00a0Losing sight of that is the danger of\u00a0doing extensive planning like I’m doing\u00a0right now.<\/p>\n
And I fell into it\u00a0this week. I got too worried about what the right way to\u00a0split up a task into objects was (dang ol’ Law of Demeter got stuck in my head). Spun my wheels in the dirt for a few days. Eventually\u00a0managed to let it go, realizing\u00a0that if this part of the code needed better modularity later it wouldn’t be hard to add it after the fact since the part that other things touched was sufficiently contained. I feel like a code hypochondriac most days, worrying about potential\u00a0problems that will likely never materialize. Which then leads me to overcompensating the other direction of embracing under-planning and ending up with an actual mess. Fortunately I only spent a couple\u00a0days on\u00a0these worries, and\u00a0I managed to stop before it became an actual problem.<\/p>\n
————————<\/p>\n
Other dumb problems I worried about this week:<\/p>\n
1.\u00a0Enumerators in Python suck, or languages with flexible\u00a0namespaces\u00a0have ruined\u00a0me<\/strong><\/p>\n This is a problem I’ve hit my head against pretty much constantly. And I still don’t have a\u00a0comfortable method to deal with it. There’s basically two common methods for\u00a0enumerators in Python. You can use magic strings which then requires extensive documentation for what the available options even are (yuck). Or you can use an object with properties representing the available constants (which is essentially the method that got incorporated into Python3).<\/p>\n What I don’t like about the latter method is that it feels incredibly overbearing to have to import the enumerator object (in my particular case I want to use enums for setting the mode of something. ie, additive or subtractive or alpha blending). Like I just want to casually manipulate this sprite object somewhere and now I have to import\u00a0something just to tell it\u00a0to be left aligned?\u00a0To say nothing of the fact that it basically requires documentation\u00a0to figure out that a method wants that specific type of enumerator in a language without strong typing (after finding out 3 has argument annotations I’m probably going to take the speed hit and finally switch to it. When you start working with a big enough codebase for long enough, no\u00a0typing leads to a lot of incredibly long argument names for the sake of clarity).<\/p>\n The closest I’ve come to what I want is to make an enumerator object of sorts that just has a bunch of methods for setting it: SetAdditive(), SetSubtractive(), etc. It’s ok I guess? I feel a little weird about it. Maybe it’s okay.<\/p>\n 2. Size and scale are different things.<\/strong><\/p>\n Because telling an SFML sprite to hit a target size is done by giving it a scale parameter, I ended up mixing up the concept of size and scale into the same component of a scene node. Specifically the properties of “match the size given by our parent sprite” and “make this sprite’s base\u00a0size match this target\u00a0size regardless of its loaded\u00a0size” ended up getting put into the scale component. This is an awful idea because you don’t want to have child scene nodes\u00a0inherit\u00a0this particular\u00a0scaling. Eventually I realized my mistake: a size component handles these things, and then the scale component scales it up, and finally the low level\u00a0sprite is given a scale to match the resulting size of the two.<\/p>\n","protected":false},"excerpt":{"rendered":" Planning is slowly coming to a close now that I’m down to API specification. Slower than I’d hoped. But I’m still managing to solve important problems so I don’t feel too terrible about the rate of progress. Programming strategies are a funny thing. For any given established design technique it’s not very hard to find… Continue reading April 27th, 2014<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-345","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/posts\/345","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/comments?post=345"}],"version-history":[{"count":1,"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/posts\/345\/revisions"}],"predecessor-version":[{"id":346,"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/posts\/345\/revisions\/346"}],"wp:attachment":[{"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/media?parent=345"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/categories?post=345"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.crabattack.org\/blog\/hawk\/wp-json\/wp\/v2\/tags?post=345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}