Reflective Programming

Reflection is an integral part of the AmbientTalk programming language. Through the use of reflection, the core language can be extended with both programming support as well as new language constructs. Both examples require a different kind of reflective access. The introduction of programming support (e.g. to visualise AmbientTalk objects) relies on introspection, the ability for a program to inspect and reason about parts of its own state. This particular flavour of reflection is quite popular and is available in most contemporary programming languages. AmbientTalk goes beyond introspection and also allows objects to supply alternative semantics for the default meta-level operations. This particular form of reflection, called intercession, allows enriching AmbientTalk from within the language itself.

The reflective model of AmbientTalk is based on mirrors, meta-level objects which allow one to reflect on an object's state and behaviour. How to create such mirrors and how they can be used is demonstrated in the first part of the tutorial. The second part of the tutorial showcases how to construct mirages, objects which override the default meta-level operations with custom behaviour. This tutorial concludes with a brief overview of the meta-level operations which are offered by AmbientTalk mirrors.

As we have mentioned in the introduction, AmbientTalk uses a mirror-based architecture to provide reflective access to its objects. The basic principle of a mirror-based architecture is that all reflective facilities are encapsulated in a mirror object which provides reflective access to precisely one object, its reflectee. Moreover, the mirror of the object is not directly accessible as a slot of the object. Instead, a separate mirror factory must be used to create mirrors, which allows the program to create different mirrors depending on dynamic conditions (e.g. what object made the request to reflect upon the object).

A convenience primitive exists that allows AmbientTalk programmers to acquire a mirror on an object without explicitly having to consult the mirror factory (the primitive does so in the programmer's stead). This primitive is called reflect:.

Once a mirror has been created, it can be used to inspect an object as a collection of so-called slot objects, objects which bind a name to a value (a method slot is simply a slot that binds a name to a method object).

def Point := object: {
  def x := 0;
  def y := 0;
  def distanceToOrigin() { (x*x + y*y).sqrt };
};
def p := Point.new(2,3);
// request a mirror on p via the mirror factory
> def mirrorOnP := reflect: p;
>><mirror on:<object:2493837>{x,x:=,...}>

>mirrorOnP.listSlots().map: {|slot| slot.name };
>>[super, super:=, x, x:=, y, y:=, distanceToOrigin]

The code excerpt presented above uses the mirror to introspect on an object and uses the listSlots meta-method. The result is a table of the slots (fields and methods) provided by this object. Notice that fields are represented as a combination of an accessor and a mutator method, conforming to the Uniform Access Principle as discussed in chapter 5. Also note that the object has a field called super, although this field was not explicitly defined. In AmbientTalk, super is defined implicitly for every object. The picture below gives an overview of the different objects involved in the actor.

The code excerpt below shows how one can add and remove slots to and from an object, and how one can explicitly access values and invoke methods upon an object, reflectively:

// let's add a z coordinate to our point
def [zaccessor, zmutator] := lobby.at.lang.values.createFieldSlot(`z,0);
// we only add the accessor, so the slot is read-only
mirrorOnP.addSlot(zaccessor);
// let's test it:
> p.z
>> 0
// we can also read slots reflectively:
> def x :=mirrorOnP.grabSlot(`x)
>> <accessor method for:x>
// and we can also invoke methods reflectively:
> mirrorOnP.invoke(p, lobby.at.lang.values.createInvocation(`distanceToOrigin,[],[]));
>> 3.605551275463989
// finally, we can remove slots...
> mirrorOnP.removeSlot(`z);

The following example contains the core of a unit testing framework by showing how to select all zero-argument methods of an object whose name starts with test and invoke them.

>def isTestMethod(meth) {
   (meth.name.text ~= "test.*").and:
   { meth.parameters.length == 0 } };
>><closure:isTestMethod>
>def retainTestMethods(obj) {
   (reflect: obj).listMethods()
     .filter: &isTestMethod };
>><closure:retainTestMethods>
>def runTest(obj) {
   retainTestMethods(obj).each: { | meth | 
     (reflect: obj).invoke(obj, lobby.at.lang.values.createInvocation(meth.name, [], [])) } };
>><closure:runTest>
>runTest(object: {def testOne() { system.println(`ok) } });
ok
>>nil

This part of the tutorial has provided a basic feeling of how AmbientTalk's default mirrors can be created and the kind of power they offer. The default mirrors offer a much wider range of capabilities than those presented in this section, however. To get a complete overview, try to inspect AmbientTalk's prototypical mirror, named defaultMirror, e.g. by using introspection:

defaultMirror.listSlots.map: { |slot| slot.name }

A complete overview of all meta-operations will be presented near the end of this chapter.

Extending the AmbientTalk core language requires adding objects which have a different implementation for some of the default meta-operations. In this part of the tutorial, we describe how a programmer can redefine the programming language's default semantics of the MOP, by means of mirages.

As a simple example, we show how to trace all method calls made on an object. The first step is to define a mirror object that encapsulates this logging behaviour. A mirror object must implement the complete AmbientTalk MOP. To make it convenient to make small changes to the MOP, AmbientTalk provides the defaultMirror, which encapsulates the default semantics. By selectively overriding this mirror's methods, we can make small adjustments to the language, e.g. as follows:

def createTracingMirror(baseObject) {
  extend: defaultMirror.new(baseObject) with: {
    def invoke(slf, invocation) {
      system.println("invoked "+invocation.selector+" on "+baseObject);
      super^invoke(slf, invocation);
    }
  }
}

The primitive mirror: is syntactic sugar for creating a new prototype that extends from the defaultMirror. Thus, we could have also defined the tracing mirror as:

def TracingMirror := mirror: {
  def invoke(slf, invocation) {
    system.println("invoked "+invocation.selector+" on "+self.base);
    super^invoke(slf, invocation);
  }
}

The next step is to create objects whose method calls can be traced. These objects will require the above tracing mirror as their implicit mirror. We call such objects with a custom implicit mirror mirages. Mirages are constructed using a variation on the object: constructor as is illustrated below.

def mirage := object: {
  def foo() { 42 };
} mirroredBy:{ |emptyBase| createTracingMirror(emptyBase) };

In the code above, the closure passed to mirroredBy: is a mirror construction closure. This closure is applied to a new, empty mirage object and it is expected that it returns a new mirror that reflects upon this mirage. When the mirror is constructed, the object initialization closure is executed.

Another alternative is to just pass a mirror prototype to object:mirroredBy:, like so:

def mirage := object: {
  def foo() { 42 };
} mirroredBy: TracingMirror;

The AmbientTalk VM will then call new on the TracingMirror prototype to create a new mirror for the given mirage object.

When invoking the method foo on the mirage, invoke will be invoked on the tracing mirror, causing the following behaviour:

> mirage.foo();
invoked foo on <obj:6276614{foo,...}>
>> 42

The picture below gives an overview of the different objects involved in the actor.

Whereas the example provided above may seem a little contrived, the reflective capabilities of AmbientTalk allow it to be extended with many abstraction relating to distributed computing for mobile ad hoc networks (AmbientTalk's main domain of application). An example language construct which is conceived as a reflective extension to the language is that of future-type message passing. Futures are discussed in the next chapter of this tutorial.

The Meta-Object Protocol of AmbientTalk can be divided into a series of independent protocols. Whereas the full semantics and signature of the meta-methods can be found in the language reference, this section provides an overview of the various protocols.

The Message Invocation Protocol consists of methods to deal with both synchronous and asynchronous method invocation. It provides necessary hooks to intercept both the reception of asynchronous messages and the invocation of synchronous messages. Moreover, it provides a hook to intercept asynchronous messages being sent by the object, allowing the object to add additional metadata to the message. The invoke meta-method illustrated above is an example of a method belonging to this protocol. The picture below gives an overview of that protocol.

The Object Marshalling Protocol consists of two methods pass and resolve, which allow an object to prescribe how it should be passed to other objects and how the object should subsequently be resolved upon arrival. The default semantics allow objects to be passed by copy if they are tagged with the Isolate type tag. Otherwise, objects are passed by handing out a far object reference.

The Slot Access and Modification Protocol consists of operations which allow trapping both dynamic access and modification to slots. For instance, o.x can be intercepted using the invokeField meta-method, while o.x := 5 is trapped using invoke where the selector will equal x:=.

The Structural Access Protocol reifies the structure of an AmbientTalk objects as a collection of slot objects. It consists of operations used list all available slots, get access to a first-class slot representation and to add new slots to an existing object. The listSlots meta-method used in previous example is a member of this protocol.

The Object Instantiation Protocol consists of the clone and newInstance methods, which are implictly called when using base-level code of the form clone: object and object.new(@args) respectively. In the default implementation, newInstance calls clone() to create a clone of the current object, and subsequently invokes the base-level init method with the supplied arguments on the cloned object.

The Relational Testing Protocol consists of the methods isCloneOf and isRelatedTo which allow testing whether 2 objects are related through cloning or a combination of cloning and object extension. Note that these operators are not able to discern that objects were generated by the same constructor function or (by extension) the execution of identical code in different actors.

The Type Tag Protocol consists of the methods isTaggedAs and listTypeTags, the former of which tests whether an object is transitively tagged with a particular type (i.e. this operation considers type tags of parent objects). listTypeTags on the other hand returns only the type tags which were explicitly attributed to this object (i.e. it does not return type tags attributed to the parent objects).

The Evaluation Protocol ensures that any AmbientTalk object can be part of a parse tree, and therefore every object provides meaningful implementations of the eval and quote meta-operations. The eval operation is called when evaluating a parsetree and typically returns the evaluated object itself, except for explicit parse-tree elements such as definition and method invocations.