-
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
,list
andrecord
. - a
platformType
, a standard data type that can contain every value of the type'skind
. - a
constraints
list, 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 :