Aerial Mage Blog

Well that's a rather obscure title, isn't it, and it'll require some explanation about some non-standard C++ structures i've been building at work. First, i've done a little bit of work in the GO programming language, and i really enjoyed the mechanics of it's non-inheriting interface polymorphism (i've called them affordance-based interfaces) Next, i found this talk explaining how to do type erasure in C++ in order to essentially emulate these affordance-based interfaces: I wrote a prototype of this system such that i could make a set of affordance classes that describe a specific member function, and might serve as a "delegate" for that function, and an interface class that could combine several of these affordance classes into a single type-erasing interface. This part actually uses a bit of "regular" polymorphism to attain it's goal, but since i've written macros that generate all the required code for you, you can effec

Today i figured i'd show, and talk about the evolution of a feature using TDD and refactoring (but mainly show). To start, i already had a tested system for adding nodes, which simply set _currentStrength to whatever node was added, but did not yet add the notion concept that these nodes were arranged in a grid, My goal was to add this feature. Starting off with a few quickfire tests to get the basic concept into place.   Blue arrows: order of steps Squares: Added/changed code. +: new test case Notice how by the end of this process i've written 5 separate test cases, and yet the thing still cannot store more than 1 item at a time ( _currentStrength is not a collection of any kind), This is a sign to "future me" that this feature still needs to be finished. This actually makes life a lot easier, since you have very obvious signs of what still needs to be done embedded into the code. C# also allows you to basically "summarize" the testcases above nicely usin