-
External tools must be able to manipulate a config tree just as easily as the creator of said tree. However, custom types prevent said tools from understanding the structure of leaves.
-
Still, custom types are very convenient to avoid systematic manual parsing.
- Therefore, the tree itself must use common types understandable by every tool, and each creator must provide mappings between common types and their own.
-
Custom types rarely have a 1:1 match with common types. Most valid values of the common types' set do not map to a valid value of a custom type (eg. not all Strings are valid Identifiers).
- This means that we also have to attach constraint information to a common type.
-
Type definitions must be serializable, as they are saved with a schema.
A new ConfigType class represents a type definition understandable by any Fiber-derived tool. It encapsulates :
- a
kind, from a non-extensible enumeration representing common base types -boolean,number,string,listandrecord. - a
platformType, a standard data type that can contain every value of the type'skind. - a
constraintslist, indexed byConstraintType(one constraint instance per constraint type).
ConfigType replaces current uses of Class in config trees. They also replace per-leaf constraints, to avoid duplication.
As an additional benefit, this change gets rid of the constraint builders and all the complexity they bring.
Class diagram :
Mapping between common and custom types is not done directly in the tree, but by extending two existing access mechanisms - annotations and property mirrors.
Property mirrors can take a TypeConverter to seamlessly convert between the common types and custom types on a per-property basis.
AnnotatedSettings already perform conversions between POJO types and nodes. This can be extended by using a TypeConverter registry internal to every AnnotatedSettings object.
Extended class diagram :
