Smalltalk-80: the language and its implementation
Smalltalk-80: the language and its implementation
Concepts and experiments in computational reflection
OOPSLA '87 Conference proceedings on Object-oriented programming systems, languages and applications
Reflective facilities in Smalltalk-80
OOPSLA '89 Conference proceedings on Object-oriented programming systems, languages and applications
Efficient method dispatch in PCL
LFP '90 Proceedings of the 1990 ACM conference on LISP and functional programming
Issues in the design and specification of class libraries
OOPSLA '92 conference proceedings on Object-oriented programming systems, languages, and applications
CLOS in context: the shape of the design space
Object-oriented programming
ECCOP '98 Proceedings of the 12th European Conference on Object-Oriented Programming
Mirrors: design principles for meta-level facilities of object-oriented programming languages
OOPSLA '04 Proceedings of the 19th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
Traits: A mechanism for fine-grained reuse
ACM Transactions on Programming Languages and Systems (TOPLAS)
Ring: A unifying meta-model and infrastructure for Smalltalk source code analysis tools
Computer Languages, Systems and Structures
| Hi-index | 0.00 |
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.