RefPredefinedTypes

The HyperGraph type system is bootstrapped by a set of predefined types that are usually loaded at startup time. Loading at startup time is not required, but is the normal practice as no atom can be accessed without having its type available.

While HyperGraph comes with a set of predefined types that should cover most real world applications, only a handful of them are absolutely necessary. Those cannot be removed or replaced with "equivalents". They form the core of the HyperGraph type system and represents the basic notions around which it is organized. Here is a list of them: • The Top type which represents that type of all predefined types. Top is special in that it stands also for the super-type of all types. Thus, in English one can say that every type is a Top, regardless of whether "is a" is interpreted in the categorical sense of "is a kind of" or in the meta sense of "is an instance of". As detailed below, when HyperGraph attempts to construct an atom of type Top, it will consider it as a predefined type and it will attempt to find its run-time instance. If it cannot, it will throw an exception. It is ok to create atoms typed with Top,for example as abstract types that can participate in sub-typing relationships, but it is not ok to attempt to create instances of them. Note however, that HyperGraph provides facilities specifically to deal with the case of abstract, non-instantiatable types when one needs to record more information about an abstract type than the fact that it is a type (e.g. abstract classes with a non-empty set of properties). • The HGLink type represents an atom that is a HyperGraph link. Instances of this type cannot be created. • The HGPlainLink type represents an atom that is a HyperGraph link and has no value associated with it. • The HGSubsumes type represents a subsumption relationship link. Subsumption is the concept used to model sub-typing, but it applies more generally to any entities.

None of those four types can be removed from HyperGraph.

By default, the predefined HyperGraph types will be automatically loaded when a new database is created and the database will be populated with them. This behavior can be disabled through a configuration parameter as documented elsewhere. Once a new HyperGraph database is created, the system will rely on whatever is in storage in order to construct its set of predefined types. An application may subsequently add other predefined types to the HyperGraph storage, or remove existing ones, except for the above list.

In general, HyperGraph cannot automatically instantiate application specific predefined types since the run-time instance of a type depends on the run-time environment from which a database is accessed (e.g. C++ or Java). Thus, the implementation of an access layer to HyperGraph in a particular programming language must provide the appropriate predefined types, identified by their persistent atom handles. Thanks to the reflection facilities in that environment, the Java implementation of HyperGraph is able to record the class name of a predefined type and provide such an automatic instantiation, whenever the predefined type is default constructible. However, in C++ an application is required to explicitly provide them every time the database is opened.

After a predefined type has been declared in HyperGraph's storage, the system will attempt to lazily get its run-time instance as soon as it is needed. If it is not in the cache, HyperGraph will give the application a chance to add it by triggering a LoadPredefinedType event. If after processing the event, the type instance is still not in the cache, the Java implementation will attempt to automatically create the instance based on the recorded class name. If the type instance is still not in the cache, an exception will be thrown. Thus, an application may choose to either add predefined types at startup or respond to the LoadPredefinedType event. Predefined types are freezed in the cache so there is no danger of them dropping out and needing to be reloaded.

The Java implementation supports automatic mapping between Java types and HyperGraph types. Moreover, this mapping is many-to-one. That is, a single HyperGraph type may map to more than one corresponding Java type. Thus when declaring a predefined type in Java, the application may associate it several different (and possibly related) Java types.