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.