Abstract. Behavioral reflection is crucial to support for example functional upgrades, on-the-fly debugging, or monitoring critical applications. However the use of reflective features can lead to severe problems due to infinite meta-call recursion even in simple cases. This is especially a problem when reflecting on core language features since there is a high chance that such features are used to implement the reflective behavior itself. In this paper we analyze the problem of infinite meta-object call recursion and solve it by providing a first class representation of meta-level execution: at any point in the execution of a system it can be determined if we are operating on a meta-level or base level so that we can prevent infinite recursion. We present how meta-level execution can be represented by a meta-context and how reflection becomes contextaware. Our solution makes it possible to freely apply behavioral reflection even on system classes: the meta-context brings stability to behavioral reflection. We validate the concept with a robust implementation and we present benchmarks.
ership basic structure, architectural elements...). Packages provide or require services. They can play core roles or Large object-oriented applications are structured over contain accessory code features. Maintainers of large applilarge number ofpackages. Packages are important but comcations face the problem of understanding how packages are plex structural entities that may be difficult to understand structured in general and how packages are in relation with since they play different development roles (i.e., class coneach others in their provider/consumer roles. This problem tainers, code ownership basic structure, architectural elewas experienced first-hand by the first author while preparing ments...). Maintainers of large applicationsface the problem the 3.9 release of Squeak, a large open-source Smalltalk [8].of understanding how packages are structured in general In addition, approaches that support application remodularand how they relate to each others. In this paper, we present ization [1, 20, 22] succeed in producing alternative views for a compact visualization, named Package Surface Blueprint, system refactorings, but proposed changes remain difficult that qualifies the relationships that a package has with its to understand and assess. There is a good support for the neighbours. A Package Surface Blueprint represents packalgorithmic parts but little support to understand their results.ages around the notion ofpackage surfaces: groups of relaHence it is difficult to assess the multiple solutions. tionships according to the packages they refer to. We present Several previous works provide information on packages two specific views one stressing the references made by a and their relationships, by visualizing software artifacts, metpackage and another showing the inheritance structure of rics, their structure or their evolution [6, 7, 10, 19, 23, 28]. a package. We applied the visualization on two large case However, while these approaches are valuable, they fall short studies: Argo UML and Squeak.of providing a fine-grained view of packages that would help This paper makes heavy use of colors in the figures. Please understanding the package shapes (the number of classes it obtain and read an online (colored) version of this paper to better defines, the inheritance relationships of the internal classes, how the internal class inherit from external ones...) and help identifying their roles within an application. In this paper, we propose Package Surface Blueprint, a IIntroduction compact visualization revealing package structure and relationships. A package blueprint is structured around the concept of surface, which represents the relationships beTo cope with the complexity of large software systems, tween the observed package and its provider packages. The applications are structured in subsystems or packages. It Package Surface Blueprint reveals the overall size and inis now frequent to have large object-oriented applications ternal complexity of a package, as well as its relation with structured ...
Abstract. Supporting read-only and side effect free execution has been the focus of a large body of work in the area of statically typed programming languages. Read-onlyness in dynamically typed languages is difficult to achieve because of the absence of a type checking phase and the support of an open-world assumption in which code can be constantly added and modified. To address this issue, we propose Dynamic Read-Only references (DRO) that provide a view on an object where this object and its object graph are protected from modification. The readonly view dynamically propagates to aggregated objects, without changing the object graph itself; it acts as a read-only view of complex data structures, without making them read-only globally. We implement dynamic read-only references by using smart object proxies that lazily propagate the read-only view, following the object graph and driven by control flow and applied them to realize side-effect free assertions.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.