can we refactor conditional compilation into aspects?
Systems software uses conditional compilation to manage crosscutting concerns in a very fine-grained and efficient way, but at the expense of tangled and scattered conditional code. Refactoring of conditional compilation into aspects gets rid of these issues, but it is not clear yet for which patterns of conditional compilation aspects make sense and whether or not current aspect technology is able to express these patterns. To investigate these two problems, this paper presents a graphical ``preprocessor blueprint'' model which offers a queryable representation of the syntactical interaction of conditional compilation and the source code. A case study on the Parrot VM shows that preprocessor blueprints are able to express and query for the four commonly known patterns of conditional compilation usage, and that they allow to discover seven additional important patterns. By correlating each pattern's potential for refactoring into advice and each pattern's evolution of the number of occurrences, we show that refactoring into advice in the Parrot VM is a good alternative for three of the eleven patterns, whereas for the other patterns trade-offs have to be considered between robustness and fine-grainedness of the advice.
refactoring conditional compilation compilation aspect software management crosscutting concern efficiency code pattern technologies paper graphics model representation interaction case studies parrot vm query evolution robust historical analysis aspicere aosd r3v3rs3 source-code