Morphtron

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

While all modern object-oriented languages have the ability to store and retrieve values, the semantics and syntax vary greatly. Prototype-based languages such as Self evolved to cope with the brittleness  that tended to creep into class based languages. MOPA accessories provide the flexibility to add properties unique to a particular object.
Ideally, as in the current implementations, the kernel exists as extensions to the root Object class so that all objects can exhibit Morphtron behavior. Then a Morphtron class is used to provide a more efficient and flexible implementation. The specification requires an executable property named supportLevelForMOPA to be implemented. This support level can be ‘full’,'nonNative’,'custom’. Although static languages and some dynamic languages will not be able to implement ‘full’ support there are significant benefits to be had from Morphtron particularly for new development and interoperability with external apps. These languages will typically specify “nonNative” support. In cases where some native support can be implemented, the support level should be ‘custom’ and then a collection of supportedMethods must be supplied.

With MOPA you can write code that quickly examines the structure and state of any object dynamically. Furthermore you can make “safer” changes by adding accessories which won’t interfere with other uses of the object. Obviously this raises integrity concerns but in the near future, Croquet will be adding capabilities based access so that individual objects will be able to prevent potentially harmful or otherwise undesirable access.
The two core kernel executable properties are applicable to any computing environment. Of course other executable properties are useful so hasProperty and removeProperty exist along with other convenience methods.

It’s worth noting that fetchProperty and putIntoProperty are the core of all modern computing down to the machine level. Logical hardware devices like microprocessors repeat these two actions over and over in patterns representing boolean logic - and, or, invert. These patterns are combined in particular sequences defined by the finite state machine described by software. Consequently, the Morphtron architecture lends itself quite nicely to hardware implementation. At the other end of the spectrum, in the context of enterprise and even more broadly distributed environments such as the web, the kernel methods are still applicable. SQL SELECT and INSERT/UPDATE are the core of relational databases while GET and PUT power the HTTP protocol of the web. In this sense, fetchProperty and putIntoProperty represent the yin and yang of computing.

Trackback this Post | Feed on comments to this Post