dimelab: shrinking the gap between talk and action.
C++ is the new assembler! We love to program, but we hate to repeat ourselves. When we strike on an idiom that increases our effectiveness, we want to use it over and over with a minimum of fuss and repetition. So naturally we turn to code generation to automate the boring bits of our code base and to instantiate useful idioms. Our affection for custom languages has led us from a handy notational device to a fully functional high-level specification language that tackles an interrelated collection of classes as the basic unit of development interest.
We designate a family of related classes as a module. A module is typically organized around the requirements of an application domain. We divide the module classes into categorical classes from unitary classes. A categorical class corresponds to a domain-specific category of objects. So for a domain like bookmark management, categorical classes could include things like bookmarks, topics, resources, bookmark catalogs, etc. Objects from categorical classes tend to refer to each other; these references represent (model) domain relationships. So a bookmark refers to a corresponding resource. A topic refers to a collection of bookmarks which have been classified to that topic. A bookmark refers to a collection of topics to which it has been classified. And so on. Given these objects and relationships, a domain-specific object-oriented data structure can be constructed, upon which useful computations can be readily provided. The data structure provides a functional model of domain objects and their relationships.
A unitary class is a domain-level class that provides useful services for working with the domain-specific object-oriented data structures that model domain objects and their relationships. We like to use a module host to encapsulate an entire domain-specific object-oriented data structure and provide meaningful (in the context of the domain) access to elements from the data structure. Many applications have a meta structure in which a host is constructed and populated, some processing is performed on the host constituents, and the host is then processes to provide some useful product. Processing a host to a useful product is facilitated with other unitary classes such as editor and viewer. Editor and viewer classes implement the venerable visitor pattern as described by Gamma et al. With cooperation from the categorical classes, the general-purpose processing of domain-specific object-oriented data structures flows along a smooth groove. With mastery of this idiom comes powerful fluidic mastery of data structures that need not make concessions to the underlying complexity of their domains!
Our module specification tool is called dish, which originally meant something like dimelab interface specification, but it's grown well beyond interface specification. Dish includes a custom language that ranges gracefully from whiteboard to notebook to your favorite editor. Backing the language are generators for code and documentation that flesh out your specification to categorical and unitary classes that you can use right away. Moreover you can generate code for getting domain-specific object-oriented data structures to and from markup and declarative discourse. As you specify your module, you are also designing a custom language (with markup or declarative discourse syntax) in which you can specify instances of the model. Extremely handy for tool building! If your custom language matures into an important tool for you, you can provide a custom syntax that further enhances the expressivity of the tool.
The dish module specifier is available as a component of our dimekit. The underlying technology is disclosed in several pending and issued patents. In Module specification language and meta-module, we describe the dish language and the meta-module that provides a domain-specific reprentation of a module and its constituents. For lovers of the printed page, here's a convenient PDF (2.8M), US PTO document 20070239773.
In Processing a module specification to produce a module definition, we describe the generation of categorical classes from a dish specification. Here's the PDF (2.7M), US PTO document 20070240110. In Producing unitary class definitions from module specifications, we describe the generation of unitary classes from a dish specification. Here's the PDF (3.3M), US PTO document 20070256051.