1. Smalltalk Meta-Programming Programming Languages HUJI 2010 Yardena Meymann

2. Unit Testing Magic The magic is called reflection, and is available to any Smalltalk programmer … you!!! How does the environment know what methods of the test case should be executed? the names of the methods are not known to SUnit framework…

3. Reflection Meta-programming is program’s ability to create/manipulate another program Reflection is the program’s ability to access and manipulate itself in a way that immediately affects (corresponds to) the actual state and behavior History – Lisp “program as data”, eval – CLOS meta-object protocol (MOP)

4. Reflection Reflective language architectures may be characterized in terms of their support for: 1.Introspection. The ability of a program to examine its own structure. 2.Self-modification. The ability of a program to change its own structure. 3.Execution of dynamically generated code. The ability to execute program fragments that are not statically known. (This is a special case of 2.) 4.Intercession. The ability to modify the semantics of the underlying programming language from within the language itself “Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Languages”

5. Metaclasses Every object is an instance of a class Every class is an instance of a metaclass Metaclasses are referred to by a message expression sending the unary message class to the instance of the metaclass, e.g. Object class In Smalltalk, if class A extends class B, then metaclass of A effectively extends metaclass of B

6. Metaclass circularity Since metaclasses are objects, they too must be instances of a class. Every metaclass is an instance of Metaclass. Metaclass itself is an instance of a metaclass. The metaclass of Metaclass must be an instance of Metaclass.

7. Some Object reflection methods perform, perform: symbol withArguments: argsArray instVarAt: index, instVarAt: index put: value class

8. Some Class reflection methods name, comment, category, fileOutOn: stream category: c, comment: text selectors, allSelectors instVarNames, classVarNames, add/remove Class/Inst VarName: var allInstances, superclass, subclasses canUnderstand: selector, inheritsFrom: class allSubclassesDo: block, allInstancesDo: block addSelector: s withMethod: compiledMethod, compile: code, removeSelector: s, copy: selector from: class new, new: size subclass: name …

9. Examples OrderedCollection instVarNames String superclass OrderedCollection canUnderstand: #size String inheritsFrom: Collection Collection selectSubclasses: [:class| class includesSelector: #addFirst:]

10. Example – AuditTrail class Just like LinkedList, but removal not supported

11. Does Not Understand Smalltalk was the first language to introduce a mechanism by which a class or object can declare a general-purpose handler for method invocations it does not explicitly support – define responses to “known” messages – by providing methods that correspond to the “known” message selectors – define responses to “unknown” messages – by implementing doesNotUnderstand: message method

12. Smalltalk Method Lookup Flow Look for method in the current class. While the method is not found, look for the method in the super- class (until class Object is reached) If method is still not found create Message object, then look for implementation of doesNotUnderstand: message using the above algorithm Message object contains the name of the method that was invoked, and the actual arguments passed Object class defines doesNotUnderstand implementation that raises an error (throws an exception)

13. Usages of doesNotUnderstand lazy loading, futures, remote proxies, orthogonal persistence, … Note: after finding the way to handle the message, the code in doesNotUnderstand may create an explicit method corresponding to the message selector

14. Proxy and meta-programming Proxy is a useful design pattern, one of many delegation-based patterns (decorator, adaptor, etc.) The problem is that every Subject class needs a corresponding Proxy class The problem can be solved by creating a universal proxy with doesNotUnderstand implementation that delegates to the subject. What else can be done?

15. become become: otherObject swaps the instance pointers of the receiver and the ar gument, otherObject. All variables in the system that pointed to the receiver will now point to the argument and vice versa. For example “lazy” proxy may after loading become the initialized object itself – Load the object, but replace its direct references with husk objects – The husks stand in for the real data on secondary storage – When you actually need to invoke a method on a husk, its doesNotUnderstand: method loads the corresponding data object from disk (but again, not transitively). Then, it does a become:, replacing all references to the husk with references to the newly loaded object, and retries the call.