{"id":314,"date":"2011-04-29T14:17:58","date_gmt":"2011-04-29T22:17:58","guid":{"rendered":"http:\/\/www.wirfs-brock.com\/allen\/?p=314"},"modified":"2011-04-29T14:17:58","modified_gmt":"2011-04-29T22:17:58","slug":"combining-mirror-facets","status":"publish","type":"post","link":"https:\/\/wirfs-brock.com\/allen\/posts\/314","title":{"rendered":"Combining Mirror Facets"},"content":{"rendered":"

\"\"<\/a>In my last couple posts I introduced idea of using Mirrors for JavaScript reflection<\/a> and took a first look at the introspection interfaces<\/a> of my jsmirrors<\/a> prototype. In this post I’m going to look at the other reflection interfaces in jsmirrors and how they are mixed together to provide various levels of reflection privilege.<\/p>\n

When building this prototype I knew that I wanted to have a number of separable sets of reflection capabilities that I could mix and match in various ways. I also knew that the implementation was likely to change several times as I experimented with the prototype. I wanted to make sure that as I evolved the implementation that I could keep track of what belonged in each separable piece. The way I ultimately accomplished this was by maintaining a file of interface definitions that are separate from the actual code that implements jsmirrors<\/a>. The interface specifications are contained in the file mirrorsInterfaceSpec.js<\/a>. I look at the interface file when I need to remind myself how to use one of the specific reflection interfaces and as a specification as I make changes to the implementaiton. Also, whenever I perform a major refactoring of the implementation I check it against the interface specification. Here is the interface specification of the basic object introspection interface that I demonstrated in the Looking into Mirrors<\/a> post: <\/p>\n

\r\n\/\/Mirror for introspect upon all objects\r\nvar objectMirrorInterface = extendsInterface(objectBasicMirrorInterface, {\r\n   prototype:  getAccess(objectMirrorInterface|null),\r\n     \/\/return a mirror on the reflected object's [[Prototype]]\r\n   extensible: getAccess(Boolean),\r\n     \/\/return true if the reflected object is extensible\r\n   ownProperties: getAccess(array(propertyMirrorInterface)),\r\n     \/\/return an array containing property mirrors\r\n     \/\/on the reflected object's own properties\r\n   ownPropertyNames: getAccess(array(String)),\r\n     \/\/return an array containing the string names\r\n     \/\/of the reflected object's own properties\r\n   keys: getAccess(array(String)),\r\n     \/\/return an array containing the string names of the\r\n     \/\/reflected object's enumerable own properties\r\n   enumerationOrder: getAccess(array(String)),\r\n     \/\/return an array containing the string names of the\r\n     \/\/reflected object's enumerable own and inherited properties\r\n   prop: method({name:String}, returns(propertyMirrorInterface|undefined)),\r\n     \/\/return a mirror on an own property\r\n   lookup: method({name:String},returns(propertyMirrorInterface|undefined)),\r\n     \/\/return mirror on the result of a property lookup. It may be inherited \r\n   has: method({name:String}, returns(Boolean)),\r\n     \/\/return true if the reflected object has a property named 'name'\r\n   hasOwn: method({name:String}, returns(Boolean)),\r\n     \/\/return true if the reflected object has an own property named 'name'\r\n   specialClass: getAccess(String)\r\n    \/\/return the value of the reflected object's [[Class]] internal property\r\n});\r\n<\/pre>\n
I used JavaScript object literals and a few helper functions to describe these interfaces.  Here is the definition of the helper functions used for this interface:<\/p>\n
\r\nfunction getAccess(returnInterface) {}; \/\/a "get-able" property\r\nfunction method(arguments,returnInterface){}; \/\/ a method property\r\nfunction extendsInterface(supers,members) {};\/\/a interface adding to supers\r\nfunction returns(returnInterface) {};   \/\/return value of a method\r\nfunction array(elementInterface) {};\/\/array elements all support a interface\r\n<\/pre>\n
The JavaScript code of the interface definitions don’t actually do anything but I find that being able to parse the interface specification using JavaScript forces me to apply some useful structuring discipline that I might skip if I was just writing prose descriptions. Plus I think it is going to be quite useful to have these interface specifications in a form that is easily processed.  For example, now that I have an initial implementation of jsmirrors, I may use it to create a little tool that can reflect upon the objects created by the interface specifications and perform useful tasks.  For example I may generate unit test stubs for implementations of the interfaces. I may also use reflection over the interfaces to directly validate the completeness of my implementations.<\/p>\n
In factoring the jsmirrors functionality for reflecting upon objects I divided it to three primary interfaces.  objectMirrorInterface<\/code>, shown above, is the basic introspection interface. objectMutationMirrorInterface<\/code> allows changes to be made to a reflected object such as adding or removing properties or changing the object’s prototype. objectEvalMirrorInterface<\/code> allows various forms of evaluation upon reflected objects such as doing “puts” and “gets” (which may invoke accessor property functions) to access property values of a reflected object or to invoke a method property.  There are also corresponding introspection, mutation, and evaluation interfaces for function object mirrors and also for property mirrors.<\/p>\n
In the actual implementation, these interfaces are combined in various ways to produce five different kinds of concrete mirrors on local objects.  These various kinds of mirrors are accessible via factory functions that are accessed as properties of the Mirrors<\/code> module object.  The five  local object mirror factories are:<\/p>\n