Partial behavioral reflection

Tanter, Éric; Noyé, Jacques; Caromel, Denis; Cointe, Pierre

doi:10.1145/949305.949309

Cited by 63 publications

(4 citation statements)

References 46 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Reflectivity improves the reflective abilities concerning both structure and behavior [16]. The Reflectivity model therefore consists of two related parts: Sub-method reflection [17] and Partial Behavioral Reflection [61].…”

Section: Reflectivity: Overviewmentioning

confidence: 99%

“…Changing the model changes the system itself, and any change to the system is reflected in the model [22]. Reflection 1 [6,15,29,30,37,46,52,53,55,61] provides the basis for a class of features for various language capabilities and tool implementation. As examples we can name run-time adaptation [44], debugging complex embedded systems in deployment [11] or tools that allow developers to explore and understand a system at run time [64].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Sub-method, partial behavioral reflection with Reflectivity: Looking back on 10 years of use

2020

View full text Add to dashboard Cite

Context. Refining or altering existing behavior is the daily work of every developer, but that cannot be always anticipated, and software sometimes cannot be stopped. In such cases, unanticipated adaptation of running systems is of interest for many scenarios, ranging from functional upgrades to on-the-fly debugging or monitoring of critical applications.Inquiry. A way of altering software at run time is using behavioral reflection, which is particularly wellsuited for unanticipated adaptation of real-world systems. Partial behavioral reflection is not a new idea, and for years many efforts have been made to propose a practical way of expressing it. Many of these efforts resulted in practical solutions, but which introduced a semantic gap between the code that requires adaptation and the expression of the partial behavior.Approach. The idea of closing the gap between the code and the expression of the partial behavior led to the implementation of the Reflectivity framework. Using Reflectivity, developers annotate abstract syntax tree (AST) nodes with meta-behavior which is taken into account by the compiler to produce behavioral variations. Reflectivity is designed for dynamically typed systems which provide an AST representation of the program that is causally connected to the source code, and which support run-time recompilation. In this paper, we present Reflectivity, its API, its implementation in Pharo, its usage and limitations. We reflect on ten years of use of Reflectivity, and investigate in the literature how it has been used as a basic building block of many innovative ideas.Knowledge. Reflectivity has been used by 21 projects in the last decade, to implement reflective libraries or language extensions, code instrumentation, dynamic software update, debugging tools and software analysis tools. Our investigation shows that developers needed powerful and customized sets of heterogeneous reflection features for their projects, which Reflectivity provided. Despite its limitations, Reflectivity has proven to be a practical way of working with fine-grained reflective operations (at the AST level), and enabled a powerful way of dynamically add and modify behavior. By instrumenting through AST annotations, Reflectivity provides a flexible means to bridge the gap between the expression of the meta-behavior and the source code.Grounding. Reflectivity is actively used in research projects. During the past ten years, it served as a support for both implementation and fundamental base, for much research work including PhD theses, papers at conferences, workshops and in journals. Reflectivity is now an important library of the Pharo language, and is integrated in the standard distribution of the platform.Importance. Reflectivity exposes powerful abstractions to deal with behavioral adaptation, while providing a mature framework for unanticipated, non-intrusive, sub-method and partial behavioral reflection based on AST annotation. Finally, the AST annotation feature of Reflectivity opens new experimentation opportuni...

show abstract

Section: Reflectivity: Overviewmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Sub-method, partial behavioral reflection with Reflectivity: Looking back on 10 years of use

2020

View full text Add to dashboard Cite

show abstract

“…Bifröst has been designed as an evolution of partial behavioral reflection for Smalltalk [RDT08], which in turn was conceived as an extension of the Reflex model [TNCC03]. Bifröst is a reflective architecture [Mae87] where meta-objects control the different aspects of reflection offered by the language.…”

Section: Bifröstmentioning

confidence: 99%

Modeling Domain-Specific Profilers.

Ressia¹,

Bergel²,

Nierstrasz³

et al. 2012

JOT

View full text Add to dashboard Cite

Domain-specific languages and models are increasingly used within general-purpose host languages. While traditional profiling tools perform well on host language code itself, they often fail to provide meaningful results if the developers start to build and use abstractions on top of the host language. In this paper we motivate the need for dedicated profiling tools with three different case studies. Furthermore, we present an infrastructure that enables developers to quickly prototype new profilers for their domain-specific languages and models.

show abstract

“…This is the same meta-regression problem that reflective systems encounter, known as the "reflective tower." [TNCC03,p. 13] In the current implementation, the injector works reflectively.…”

Section: Dependency Injection As a Language Featurementioning

confidence: 99%

Seuss: Decoupling responsibilities from static methods for fine-grained configurability.

Schwarz¹,

Lungu²,

Nierstrasz³

2012

JOT

View full text Add to dashboard Cite

Unit testing is often made more difficult by the heavy use of classes as namespaces and the proliferation of static methods to encapsulate configuration code. We have analyzed the use of 120 static methods from 96 projects by categorizing them according to their responsibilities. We find that most static methods support a hodgepodge of mixed responsibilities, held together only by their common need to be globally visible. Tight coupling between instances and their classes breaks encapsulation, and, together with the global visibility of static methods, complicates testing. By making dependency injection a feature of the programming language, we can get rid of static methods altogether. We employ the following semantic changes: (1) Replace every occurrence of a global with an access to an instance variable; (2) Let that instance variable be automatically injected into the object when it is instantiated. We present Seuss, a prototype that implements this change of semantics in Smalltalk. We show how Seuss eliminates the need to use class methods for non-reflective purposes, reduces the need for creational design patterns such as Abstract Factory and simplifies configuration code, particularly for unit tests. We present benchmarks showing that Seuss introduces a 34 % additional memory cost, and runs at 53 % speed, without any optimizations.

show abstract

Partial behavioral reflection

Cited by 63 publications

References 46 publications

Sub-method, partial behavioral reflection with Reflectivity: Looking back on 10 years of use

Sub-method, partial behavioral reflection with Reflectivity: Looking back on 10 years of use

Modeling Domain-Specific Profilers.

Seuss: Decoupling responsibilities from static methods for fine-grained configurability.

Contact Info

Product

Resources

About