Differences

This shows you the differences between two versions of the page.

--- at:tutorial:reflection [2008/08/01 14:42] – * tvcutsem
+++ at:tutorial:reflection [2008/09/15 17:39] – tvcutsem
@@ Line 3: / Line 3: @@
 [[wp>Reflection_(computer_science)|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 [[http://bracha.org/mirrors.pdf|mirrors]], meta-level objects which allow one to reflect on an objects 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.
+The reflective model of AmbientTalk is based on [[http://bracha.org/mirrors.pdf|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.
 ===== Mirrors =====
-As we have already 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 factory must be used to create mirrors, which allows the program to hand out different mirrors according to the dynamic call chain, the requesting object etc. The factory can be used implicitly using the ''reflect:'' primitive. Once a mirror has been created, it can be used for instance to produce a listing of an object's methods, as is exemplified below.
+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).
 <code>
->def mirrorOnOne := reflect: 1;
+def Point := object: {
->><mirror on:1>
+  def x := 0;
->mirrorOnOne.listMethods();
+  def y := 0;
->>[<native method:==>, <native method:+>,
+  def distanceToOrigin() { (x*x + y*y).sqrt };
-   <native method:<=>>, <native method:to:do:>, ...]
+};
+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]
 </code>
-The code excerpt presented above uses the mirror to //introspect// on a natively implemented object (the number 1) and uses the ''listMethods'' meta-method. The result is a table of the methods provided by this object, including the comparators ''=='' and ''<=>'', operations such as ''+'' and the enumeration construct ''to:do:''. Since the number 1 is a natively implemented object, all of its methods are provided with builtin implementations. This can be witnessed from the example since all methods are denoted to be native methods.
+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.
-When reflecting upon a user-defined object, we can observe that every object has some implictly defined methods and fields, in addition to those which are defined when constructing the object. Every AmbientTalk object has a ''super'' field as well as primitive implementations for the methods ''=='', ''new'' and ''init''. The primitive methods play a somewhat peculiar role in an object since they are present in every object, yet they can be safely overridden without leading to a name clash (which normally occurs when one object attempts to define two methods with the same name).
+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:
 <code>
->def inspectable := object: {
+// let's add a z coordinate to our point
- def map(arg1, @restArgs) { restArgs.map(arg1); } };
+def [zaccessor, zmutator] := lobby.at.lang.values.createFieldSlot(`z,0);
->><obj:{super,super:=,map}>
+// we only add the accessor, so the slot is read-only
->def mirrorOnInspectable := reflect: inspectable;
+mirrorOnP.addSlot(zaccessor);
->><mirror on:<obj:{super,super:=,map}>>
+// let's test it:
->mirrorOnInspectable.listFields()
+> p.z
->>[<field:super>]
+>> 0
->mirrorOnInspectable.listMethods()
+// we can also read slots reflectively:
->>[<method:map>, <primitive method:new>,
+> def x :=mirrorOnP.grabSlot(`x)
-   <primitive method:init>, <primitive method:==>]
+>> <accessor method for:x>
->def method := mirrorOnInspectable.grabMethod(`map);
+> x()
->><method:map>
+>> 2
->method.bodyExpression
+// and we can also invoke methods reflectively:
->>restArgs.map(arg1)
+> mirrorOnP.invoke(p, lobby.at.lang.values.createInvocation(`distanceToOrigin,[],[]));
+>> 3.605551275463989
+// finally, we can remove slots...
+> mirrorOnP.removeSlot(`z);
 </code>
-Using a mirror on an object, it is possible to get access to a representation of the object's methods and fields, allowing the programmer to read the value of a field, or as is exemplified above inspect the body of a method. This type of reflection is quite useful to for instance construct an inspector for live AmbientTalk objects.
+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.
-In addition to allowing a program to reason about the structure of its objects, mirrors can also be used to perform operations such as method invocation in a first-class manner. The following example shows how to select all zero-argument methods whose name starts with ''test'' and invoke them.
 <code>
 >def isTestMethod(meth) {
    (meth.name.text ~= "test.*").and:
-   { meth.parameters == [] } };
+   { meth.parameters.length == 0 } };
 >><closure:isTestMethod>
 >def retainTestMethods(obj) {
@@ Line 52: / Line 65: @@
 >def runTest(obj) {
    retainTestMethods(obj).each: { | meth |
-     (reflect: obj).invoke(obj, `(.#(meth.name)())) } };
+     (reflect: obj).invoke(obj, lobby.at.lang.values.createInvocation(meth.name, [], [])) } };
 >><closure:runTest>
 >runTest(object: {def testOne() { system.println(`ok) } });
@@ Line 59: / Line 72: @@
 </code>
-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. A complete overview of all meta-operations will be presented in the final chapter of this tutorial.
+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:
+<code>
+defaultMirror.listSlots.map: { |slot| slot.name }
+</code>
+A complete overview of all meta-operations will be presented near the end of this chapter.
 ===== Mirages =====