Midgard and the Properties pattern

Steve Yegge’s long discussion of an universality of a Properties pattern can be supplemented with a Midgard as an example. Midgard itself represents its “objects” as a set of properties with links within and between object hierarchies to represent relations. All those articles, topics, pages, sites and so on represent a Prototype pattern design pretty well though once application has started its structure and objects’ set of properties cannot be changed. We even represent code parts and dependencies as data with snippets and page elements. In Vinland release even messaging about property-related activities will work (send event to subscriber if an article’s title has been changed or it is moved to a different topic, for example).

What lacks from Midgard’s implementation of the Properties pattern, is an ability to treat actions performed on objects and their properties as first-class objects. There is little in the Midgard’s core that allows you to operate activities as part of object’s structure, resulting effectively in closures and other niceties of good programming languages unavailable at schema definitions. We currently imitate much of it with a help of PHP5 or Python on an user application level but that isn’t convenient and is not portable across all the languages. We try to overcome this by introducing language-neutral communication channels like D-Bus to signal and perform actions across language boundary but still lack of activity’s integration into the object’s structure makes it suboptimal.

What could be done to overcome it? First, we could introduce a notion of callable property for Midgard schemas, turning our (implied) getters/setters into a proxy that calls specific interfaces which can be announced and subscribed to by an user application or by a Midgard core itself (for relation purposes, for example). Upon loading the schema, Midgard core would create appropriate GObject classes and implement proxy methods for callable properties, similar to what is done in GTK+ UI builder. The real difference would be to have these method callers to propagate through language boundaries, giving an application developer an easy way to connect his specific activities to object hierarchies. This could reduce fair amount of class inheritance and simplify applications.

Second, above change is applied to a class hierarchy. It doesn’t allow you to handle an instance differently to what class supposed to do. Augmenting any property of an instance at run-time with some closure would actually help here. It also helps for more targeting caching of the data handled by the property.

From a Property pattern one thing that makes little sense for Midgard object’s properties is a property removal. As Midgard application is backed by some store (SQL currently), removing property means damaging a structure of the store. However, making possible to remove callable properties might make sense. It also could be a nice to allow removing (making inaccessible) properties to provide sand-boxing and similar features. This approach could make more natural some operations, like “killing” an article—just prune its connection with a parent topic.