types and manually invoke them. This works for project-internal files as well as external libraries such as .NET's assemblies and Java's archives. Implementation A language supporting reflection provides a number of features available at runtime that would otherwise be difficult to accomplish in a lower-level language. Some of these features are the abilities to: Discover and modify source-code constructions (such as code blocks, classes, methods, protocols, etc.) as first-class objects at runtime. Convert a string matching the symbolic name of a class or function into a reference to or invocation of that class or function. Evaluate a string as if it were a source-code statement at runtime. Create a new interpreter for the language's bytecode to give a new meaning or purpose for a programming construct. These features can be implemented in different ways. In MOO, reflection forms a natural part of everyday programming idiom. When verbs (methods) are called, various variables such as verb (the name of the verb being called) and this (the object on which the verb is called) are populated to give the context of the call. Security is typically managed by accessing the caller stack programmatically: Since callers() is a list of the methods by which the current verb was eventually called, performing tests on callers()[0] (the command invoked by the original user) allows the verb to protect itself against unauthorised use. Compiled languages rely on their runtime system to provide information about the source code. A compiled Objective-C executable, for example, records the names of all methods in a block of the executable, providing a table to correspond these with the underlying methods (or selectors for these methods) compiled into the program. In a compiled language that supports runtime creation of functions, such as Common Lisp, the runtime environment must include a compiler or an interpreter. Reflection can be implemented for languages without built-in reflection by using a program transformation system to define automated source-code changes. Security considerations Reflection may allow a user to create unexpected control flow paths through an application, potentially bypassing security measures. This may be exploited by attackers. Historical vulnerabilities in Java caused by unsafe reflection allowed code retrieved from potentially untrusted remote machines to break out of the Java sandbox security mechanism. A large scale study of 120 Java vulnerabilities in 2013 concluded that unsafe reflection is the most common vulnerability in Java, though not the most exploited. Examples