Chapter 56. Model Ignorant Generation

Hardcode all logic into the generated code so that there’s no explicit representation of the Semantic Model.

56.1 How It Works

One of the advantages of code generation is that it allows you to produce code that would be too repetitive to write by hand in a controlled way. This opens up implementation options that, usually, you would wisely shy away from because of duplicating code. In particular, this allows you to take behavior usually represented through data structures and encode them in control flow.

To use Model Ignorant Generation, I can start by writing an implementation of a particular DSL script in the target environment. I prefer to start with a very simple and minimal script. The implementation code should be clear, but can freely intermingle generic and specific code, and I don’t have to worry about repetition in the specific elements, since these will be generated. This means I don’t have to think about clever data structures, usually preferring procedural code and simple structures.

56.2 When to Use It

Target environments often involve languages with limited facilities for structuring programs and building a good model. In these situations, it’s not possible to use Model-Aware Generation, so Model Ignorant Generation is pretty much the only option. The second main reason for using Model Ignorant Generation is when using Model-Aware Generation results in an implementation that demands too much runtime resources. Encoding logic in control flow may reduce memory needs or increase performance; if these are sufficiently critical, then Model Ignorant Generation is a good way to get there.

On the whole, however, I prefer to see Model-Aware Generation if it’s possible. It’s usually easier to generate code with Model-Aware Generation, which results in a generation program that’s simpler to understand and modify. Having said that, using Model Ignorant Generation often makes the generated code easier to follow. This has the converse effect that it can be easier to figure out what to generate, although harder to write the code to generate it.

56.3 Secret Panel State Machine as Nested Conditionals (C)

Again, I’ll turn to the secret panel state machine I used in the Introduction. One of the classic state machine implementations uses nested conditionals which allow you to evaluate your next step using conditional expressions based on your current state and the received event. For this example, I’ll show what a nested conditional implementation for Miss Grant’s controller would look like. To see how I might generate this code, see the example in Templated Generation.

There are two conditions that I need to evaluate: the incoming event and the current state. I’ll start with the current state.

Testing the state involves a static variable which holds the current state.

Each subsidiary function now does a further conditional check based on the received event. Here’s the case for the active state:

The other subsidiary functions look very similar, so I won’t repeat them. While this code would be too repetitive to write by hand for different machines, when generated it is quite easy to follow.