Originally, Haystack was designed with a mechanism for dynamically adding new object types to the HDM. If there was not a class definition (in the Java sense) for an object, a ``generic'' Straw would be created with the appropriate type field set to the new value. This approach, unfortunately, caused a breach of abstraction barriers and the strong typing enforced by Java. Until a Haystack type checking mechanism is implemented, a more modest approach was necessary.
All objects defined within the HDM model have an associated Java implementation. The Java implementation can be a simple stub, and does not need to provide any additional functionality. It is not necessary to recompile any portions of Haystack to add new Straw sub-types, but it is necessary to compile the stub.
The other fundamental invariant of the HDM model is the package/class hierarchy. To extend one Straw class, a package is created with the Straw name in all lower case letters. All extensions to the original Straw are placed within that package. For example, in Haystack we have a generic needle.Filetype object (notice the upper case). Let us also assume that we have some agent (human or computer) that is interested in all Postscript files that enter into a Haystack. If needle.Filetype was the ``deepest'' we went, the agent would, inefficiently, have to check inside every single needle.Filetype to decide which are Postscript and which aren't. However, we already know which documents are Postscript and can make this more obvious to interested agents. To do this we create the package, needle.filetype (notice the lowercase). We can then create the class, needle.filetype.Postscript, which will reside in this package and extend the needle.Filetype object. The Postscript specific Needle can still be casted (i.e. converted) to a needle.Filetype, but it is now possible to tell what the Needle will contain by just looking at the type information of the object.
The only other requirement for extensions of the HDM is that all
Straws must extend an object residing one level higher in the
package hierarchy
. Formally: " classes a.b...i.j.K $ class
a.b...i.J, where {a,b,c,...,z} are parts of a package
path and {A,B,C,...,Z} are class names. In our previous example, for
needle.filetype.Postscript to exist, needle.Filetype
had to exist.