DAVE'S LIFE ON HOLD

Mirror mirror

NB: The current version is now live as a Google AppEngine webapp located at: http://www.dloh.org

I've been playing around with improving the mirror capabilities of Phos and have put together a little demo suggested by Randy Smith as follows:



The basic concept here is modifying a text Block element by dropping other Block objects onto the original Block's Mirror. To obtain the Mirror instance, we simply call mirror() on any object. Once we have that entity, we can dynamically alter any property of the object by performing operations on its mirror that would be outside of the behavior of the object itself.

Gilad Bracha and David Ungar wrote a paper not to long ago about the need for encapsulating the meta-programming level stuff, and when you actually use a system with live objects this requirement becomes self evident. For example, once can not easily just "add a feature" to an object by dropping a feature object onto it, as the default behavior for most objects will be "respond to that message". If you provide a message for "add a feature", quickly everything becomes a meta-level problem.

I went down this route initially and end up with an object understanding "application stuff" and also understanding "programming stuff", which was the original Block. The new Block vs. Mirror structure, made meta-programming on the block easier, and reduce the Mirror to a collection of Blocks, which knew how to operate on generic objects. While I'm still not happy with the current Mirror object, it will ultimately become an organizing structure like a Tree or an Array.

Back to Bracha & Ungar's paper.... In it they define 4 terms of art:


  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



Currently the Phos environment supports Introspection largely through Mirrors, Self-modification through Blocks + Mirrors, and execution of dynamically generated code through Block value() and a new style eval that I'm calling a Selection Eval as per this video:



In the not too distant future, I plan on support some additional layers of Intercession, mostly to ease the job of programmers when typing in behavior definitions in Blocks. The underlying programming language itself is significantly less important when you have objects that are directly manipulable and respond to messages. If one could easily use objects for property names, there would be little preventing methods from being named by icons. One could then send a message to an object to invoke a method by dropping, clicking, or hovering over an icon just as easily as passing a block with a function name. Obviously, things like code comments mean very little when you have live objects which can pop-up their own tool tips! And do you really need to type function ()  </i> over and over again, if you could just populate a different color block