End-user abstractions for meta-control: Reifying the reflectogram

N. Papoulias, M. Denker, S. Ducasse, L. Fabresse
2017 Science of Computer Programming  
Reflective facilities in OO languages are used both for implementing language extensions (such as AOP frameworks) and for supporting new programming tools and methodologies (such as object-centric debugging and message-based profiling). Yet controlling the runtime behavior of these reflective facilities introduces several challenges, such as computational overhead, the possibility of meta-recursion and an unclean separation of concerns between base and metalevel. In this paper we present five
more » ... mensions of meta-level control from related literature that try to remedy these problems. These dimensions are namely: temporal and spatial control, placement control, level control and identity control. We then discuss how these dimensions interact with language semantics in classbased OO languages in terms of: scoping, inheritance and first-class entities. We argue that the reification of the descriptive notion of reflectogram can unify the control of meta-level execution in all these five dimensions while expressing properly the underlying language semantics. We present an extended model for the reification of the reflectogram based on our additional analysis and validate our approach through a new prototype implementation that relies on byte-code instrumentation. Finally, we illustrate our approach through a case study on runtime tracing. describes, reflects or defines the behavior of a notion of the language in question [13] . The process of materializing a notion of a language (such as an object, a class, a context or a method) as an object inside the language itself is called reification. Reflective facilities in OO languages [5] are used both for implementing language extensions such as AOP frameworks [29] and for supporting new programming tools and methodologies such as object-centric debugging [23] and message-based profiling [1] . Yet, controlling the runtime behavior of reflection introduces several challenges such as computational overhead [14] , the possibility of meta-recursion [6, 7] and an unclean separation of concerns between base and meta-level [2]. These problems arise mainly when implicit reflection (i.e., reflection that is activated implicitly by the interpreter on pre-defined execution events [14] ) alters the semantics of a running process in ways that lead to excess overhead or inconsistencies. Although implicit reflection involves complicated modeling concerns, it is useful to consider it -in its most simple form -as operating similarly to an Event-Condition-Action model [8, 30] . In a class-based OO language the ECA model would be depicted as shown in Figure 1 . The Event (left part of Figure 1 ) in the case of implicit reflection is a semantic action of the underlying interpreter (e.g., read/write slot, message send, method execution etc.) while both Condition and Action can be considered as custom code snippets (such as block closures) defined by the developer. Registration of such events can take the following form (code presented in Smalltalk syntax): Script 1: Implicit Reflection Example 1 MsgSend 2 when: [ countingFlag = true ] 3 do: [ messageCounter := messageCounter + 1 ]
doi:10.1016/j.scico.2016.12.002 fatcat:svhsuc37trftdk2ojs4lxg5wrm