Morphtron

A full implementation of Morphtron provides a common, transparent means of providing access to properties by using the native property if it exists. In cases where no native property exists, MOPA methods then use or optionally create an accessory. For example consider this Smalltalk(Squeak and Dolphin) implementation of fetchProperty:

fetchProperty: aSymbol
| property |
property _ self fetchNativeProperty: aSymbol.
property
ifNotNil: [^ property].
^ self fetchAccessory: aSymbol

The details of fetchNativeProperty are left up to the implementor. She can determine what access to native properties will be allowed. The following Smalltalk implementation this:

fetchNativeProperty: aSymbol
| ivarValue |
(self class allInstVarNames includes: aSymbol)
ifTrue: [”aSymbol is an ivar”
(self isPrivateInstVar: aSymbol)
ifFalse: [”aSymbol has not been declared private”
(self class lookupSelector: aSymbol) isNil
ifTrue: [self allowInstanceVariablePropertiesWithoutAccessors
ifTrue: [ivarValue _ Compiler
evaluate: ‘^’ , aSymbol asString
for: self
logged: false]]
ifFalse: [ivarValue _ self perform: aSymbol]]].
^ ivarValue

Now for a prototype-based language such as Javascript, things are simplified because all properties are native:

function fetchProperty(aName) {

/*

Using fetchProperty for accessing properties has a number of different benefits. It is easier for beginner-to-intermediate programmers and allows Morphtron behaviors to be ported between different object environments. It also lets accessories be used transparently as properties. That said, a programmer with sufficient knowledge can still use built-in properties and accessories however she wants. See also fetchAccessory. One interesting use of accessories is for undo.

*/

var theProperty=this[aName];

if(typeof(theProperty)==’undefined’) {

theProperty=this.fetchAccessory(aName);

}

return(theProperty);

}

MOPA provides two capabilities:

• a uniform, largely syntax neutral means of interfacing with an object’s native properties/fields/instance variables/methods.
• a uniform, largely syntax neutral means of interfacing with properties unique to a particular instance.These unique instance properties are referred to as accessories.

The “largely syntax neutral” disclaimer is made because Morphtrons could be difficult or even impossible to fully implement in every dynamic OO language. These two capabilites make it possible to write code which can be directly executed by multiple languages across multiple platforms.

There are two executable properties which form the kernel of a Morphtron implementation.

• fetchProperty
• putIntoProperty

Continue Reading »

To facilitate implementation and extension, the Morphtron architecture has been modularized into the Morphtron Programming Framework(MPF). The MPF nucleus is known as the Morphtron Object Properties and Accessories(MOPA). A Morphtron object is a collection of named properties. There are two categories of Morphtron properties - Executable and Value, each having two sub-categories Native(as determined by the host language - typically by the class) and Accessory(unique to an instance). MOPA provides the means to create, store and retrieve an object’s properties. Surrounding the Morphtron nucleus is Morphtron Components and Containers(MC2) module which provides objects with the ability to exist in hierarchical relationship to other objects. Another module is called Morphtron Observation Interchange Storage & Transport(MOIST). This is actually a collection of four interrelated sub-modules whose names reflect their function. Each of these modules will be covered in more detail later.

I had an inspiring conversation(thanks Dwight!) with an old Smalltalker who’s doing PHP 5 and Ruby these days. This short discussion has moved me to shift gears a bit and start pushing the Morphtron Programming Framework(MPF) forward again. In recent times, MPF has been pushed back several notches in order to address the needs of the broader market of non-programmers. Ideally, you want to have all of the lower level infrastructure frozen before doing this but the Morphtron architecture coupled with the time-based message passing of GVScript let’s you reap some benefits of stretching extreme late binding a bit further without changing the underlying language. In addition, I’ve used this framework for so long in multiple languages across different platforms in many applications including production environments and I’m not concerned about the current loose ends. The priorities I\’d been dealing with were:

• GriotVision pre-built virtual worlds
• GVScript core virtual world classes(GVSpace)
• GVScript visual editor
• GVScript core classes

These all build upon MPF so experienced developers can look at them as examples. However, I’ve got to get the core MPF code concepts out to give people something to work with. So with this blog is going to be the vehicle. Buckle up because the ride will be bumpy in places.