Evolving a reflective language: lessons learned from implementing traits

Traits are method groups that can be used to compose classes. They do not have a runtime existence and are conceptually folded into the classes that use them. Traits have been implemented in different languages. While implementing them in Smalltalk, our first reflex was to take advantage of the fact that traits are not run-time entities: we optimized the implementation for space and hence shared methods between traits and classes. However, by doing so we broke the introspective API of Smalltalk. This paper illustrates a more general problem seen in all reflective systems: the implementation serves both as a model for execution and as the model that is exposed to the programmer. There is a conflict of interests between the information necessary for execution and the information the programmer is interested in. In addition, as soon as the implementation is exposed via reflection, we are not free to optimize. As the complete implementation is visible reflectively, there is no way to hide the optimizations. Few papers report errors and this is one of them. We report our experience facing the initial API mismatch, which has a significant impact on the system because the language is reflective (i.e., written in itself and causally connected). We present the new introspective API we put in place.