Linguistic Reflection Via Mirrors

Transcription

1 Linguistic Reflection Via Mirrors Gilad Bracha Joint work with David Ungar 1

2 Reflection: Overview Reflection is the ability of a program to manipulate itself More than just metaprogramming Earliest Reflective Language? 2

3 Reflection: Overview (2) Earliest Reflective Language: EDVAC/ EDSAC/Manchester Mark I Reflection is Inherent in the Von Neumann Architecture: stored program computer treats its own program as data How to structure this power in HLLs? 3

4 Introspection Reflective functionality can be divided into several distinct parts Introspection: Read only access to the program Incomparable to the notion of programs as data. Stronger - we need this program as data (so it's not just metaprogramming) Weaker - read only; e.g., cannot create programs. Java supports introspection through core reflection 4

5 Introspection: Example class Introspector { public static void main(string[] args) { Introspector i = new Introspector(); Class myclass = i.getclass(); for (Method m : myclass.getmethods()) System.out.println(m); } 5

6 Self-modification (1) Changing the current computation as it executes: Routine in Smalltalk, Self, Erlang, Lisp, Prolog, APL Limited support in JDI Enables breakpointing, fix and resume debugging, some forms of profiling 6

7 Self-modification (2) Self-modification subsumes more restricted functionality, such as: Executing data that represents code, e.g., Method.invoke() Creating new code as in ClassLoader.defineClass() 7

8 Intercession Modification of the language semantics: CLOS MOP is most extensive example More limited form in Smalltalk Class loaders allow for load-time intercession We won't discuss intercession further 8

9 Mirror Overview Mirror = an object that reflects another object. Three principles: Encapsulation: Clients of reflection must not depend on specific implementation of reflection, only on interface. Stratification: There must be a clean separation between the reflective and nonreflective levels. Correspondence: model the programming language structurally and temporally 9

10 Mirror Overview (2) Mirrors are the application of good OO software engineering to the reflective facilities of the language. Mirror implementations: Self (origin of idea) Strongtalk JDI APT 10

11 Traditional API Usage: Define Class anobjectsclass; SomeClass anobject; anobjectsclass = anobject.getclass(); Then, query a class for its superclass Class anobjectssuperclass; anobjectssuperclass = anobjectsclass.getsuperclass (); 11

12 Traditional API (2) class Object { Class getclass();... } class Class { Class getsuperclass();... } 12

13 Traditional API (3) Traditional APIs support reflection at the core of the system. Every object has at least one reflective method, which ties it to Class and (most likely) an entire reflective system. 13

14 Mirror based API class Object {... // no reflective methods } class Class {... // no reflective methods } interface Mirror { // in JDI, tostring() and virtualmachine() go here 14

15 Mirror based API (2) class Reflection { // called Bootstrap in JDI // In JDI, creates a VMManager which creates VMMirror Mirror reflect(object o); } // called ObjectReference in JDI interface ObjectMirror extends Mirror { ClassMirror getclass();... // referencetype() in JDI } // called ClassType in JDI interface ClassMirror extends Mirror { ClassMirror getsuperclass();... // superclass() in JDI } 15

16 Mirror based API Usage Object anobject; ObjectMirror anobjectmirror; ClassMirror anobjectsclassmirror, anobjectssuperclassmirror; anobjectmirror = Reflection.reflect(anObject); anobjectsclassmirror = anobjectmirror.getclass(); anobjectssuperclassmirror = anobjectsclassmirror.getsuperclass(); 16

17 Advantages of Mirrors Distribution Clients can interact with metadata sources that are local or remote w/o change to the client. JDI is an existence proof of distribution. A client can interact with multiple sources of metadata at run time, and interact with metaobjects from different implementations simultaneously. 17

18 Example: A Class Browser a. Write a class browser using core reflection b. Want to reuse code for distributed browsing 18

19 Switching Implementations One can switch implementations by modifying an import statement. Replace: import java.lang.reflect.* with import com.moi.reflection.* Some adaption needed in client (exception handling, maybe distributed GC), but once done, new version will work local or remote 19

20 Problems with Imports 2 source programs to maintain. 2 sets of binaries to distribute. Twice the code footprint. Hard for two versions to interoperate. Moral: imports are for coupling things, not decoupling. They just localize the coupling. 20

21 Problems with Imports (2) A 3rd task (c) browse from source (use parser). Again, small changes at top level. Now 3 sources, binaries, runtime versions. But, if you design (b) to an interface, (b) and (c) can be shared. In practice (a) is core reflection, (b) is JDI, and (c) is doclets/apt. 21

22 Relation to Type System The type system (or its absence) can help prevent implementation dependency. Options: 1) Structural type system 2) Nominal type system based exclusively on interfaces 3) Optional type system (with 1 or 2) 4) Dynamic typing 22

23 Relation to Type System (2) If you design a new reflective API, you might think that you can control the type system design. In practice, reflection is often added to an existing language as an afterthought (e.g., Java, MetaBeta). 23

24 Relation to Type System (3) So if you don't have one of the options 1-4? If the language at least supports interfaces, use them as much as possible! If not, use abstract classes. 24

25 Encapsulation => Stratification Exposing the class of an instance makes proxies detectable Examples: getclass(), casts, instanceof Mirrors can eliminate getclass(), but in some languages, classes have base-level semantics (e.g., instance creation in Smalltalk) Beware of identity issues 25

26 Security Stratification implies easy to identify entry point for reflection Very beneficial for security one entry point to protect easier to reason about, implement correctly 26

27 Deployment Dynamic languages failed to separate out the meta level. Classes in Smalltalk and CLOS are both meta- and non-meta-objects. Class methods and class variables are an issue. Cannot be avoided - instance construction is a class method. Difficult to deploy non-reflective applications written in reflective languages on platforms without a reflective implementation. 27

28 Deployment (2) Examples: Small devices or embedded systems Applications where footprint, security or bandwidth discourage/preclude deployment of built-in reflection support. 28

29 Relation to Type System (4) Mandatory nominal type system makes it easy to track what functionality is used. Not that easy with either structural (1), optional (3) or dynamic (4) type systems. Intersection with 1-4 yields 2 (nominal with interfaces only) as insurance against design failure. Many other considerations dictate optional nominal system with interfaces only + careful mirror based design 29

30 Deployment and Types Mandatory nominal type system with only interfaces can help avoid deployment of reflection However, if one wishes to deploy reflection dynamically, mirrors are still necessary Given disadvantages of mandatory type systems, mirrors are essential 30

31 Deployment + Distribution Interesting capabilities Remote debugging of mobile phones smart appliances Adding reflection to a running computation. Possible with Klein, experimental metacircular VM based on Self 31

32 Other issues Reflecting the HLL or the VM Reflecting method bodies Code vs. Computation Metadata Unifying Reflection and Metaprogramming 32

33 Reflect at source level or VM level? Implementation requires reflective access to VM Which Language to Reflect? VM may support high-level language(s) with different semantics Each HLL must have its own reflective API, or semantic discrepancies will arise Strongtalk is only mirror system that separates mirrors into low and high levels. 33

34 Example: Nested Classes in Java VM does not directly support nested classes Compiler uses synthetic members as part of translation from HLL (Java) to VML (Java byte code) Core reflection exposes all members, synthetic or not, exposing translation strategy 34

35 Reflecting Method Bodies Traditional reflective APIs do not reflect the internals of a method Debuggers need this; APIs often provide raw byte code (VML) which clients attempt to decompile Issues: ability to reconstruct source 35

36 Code vs. Computation The word program is ambiguous Must distinguish between Code: A description written in some programming language Computation: An executing computational process Code is intentional, declarative, static Computation is extensional, stateful, dynamic 36

37 Code vs. Computation An API like JDI is not well suited to writing a class browser that examines source files Notions like active threads, call stacks, object instantiation assume a computation Conversely, source code contains things like comments that might not be available at run time Metaprogramming APIs should model the commonalities and distinctions between code and computation (2) 37

38 Metadata User-defined metadata is a fashionable topic Allows programmers to add user-defined annotations to ASTs Popularized by C#; Being added to Java 38

39 Metadata (2) Many of the same issues arise: Code vs. Computation - should all metadata be retained at run-time? Reflecting method bodies: Some metadata (like types) requires ability to add metadata to every node of AST Distribution: Access metadata remotely, transparently 39

40 Unifying Reflection and Metaprogramming If one models the ontology of the programming language, both structurally and temporally, one may be able to unify reflection and metaprogramming Use consistent framework for compilers, assemblers, debuggers, browsers and for reflection Example applications: javac, javap/ jdis/jasm/jcod, verifier, JIT. 40

41 The Goal? The ideal reflective API: Corresponds to the language, structurally and temporally Respects encapsulation and stratification Supports introspection, selfmodification and intercession Are these goals mutually consistent? 41

42 Related Work Self Strongtalk JDI Wirfs-Brock/Smalltalk Firewall MOP Class loaders Templ/Oberon MetaBeta, Yggdrasil 42