Standardize the definition of "type" for TOML property definitions
So, starting with basic types:
-
number
(float/int) -
integer
(no real difference over the RPC call, but more restrictive than number in intent) boolean
-
string
(Assume UTF-8) -
null
(likely only used if we define defaults, as returns are just left off, doesn't make much sense for arguments)
Composite types get harder... Some cases to consider:
- Properties which take arbitrary type
- Properties which take some subset of types (potentially including composite types)
- Heterogeneous arrays of exactly
n
items (think more like python tuples than arrays, but JSON limits) - Homogenous typed arrays of known (potentially large) size
- Homogenous arrays of arbitrary (not specified in definition) size
- Dictionary which contains a specific set of keys
- Dictionary which has exactly given keys (no more, no less)
- Multidimensional arrays
So far, our type definitions are strings. Starting some proposals for discussion:
- "any" as a type key for arbitray types
- "|" for union types (e.g. "number|string")
- "[type, type]" for tuple-like, small, specifically sized (and heterogeneous arrays)
- "[type*n]" for homogenous, known size (alternative "type[n]", or just don't specify size in type definition)
- "[type, ...]" for arbitrary sized homeogenous arrays (alternative "type[]")
- "{key: type, ...}" for dictionary which contains keys
- "{key1:type, key2:type}" for dictionary which has exactly given keys
- "[[type]]" for multidimensional arrays (does not scale well to large dimensions, alternative "type[n,m]")
Some concrete examples from our codebase to consider:
-
id
gets "units" added as key by a trait -
help
returns either string or array of string, with optional parameter -
set_state
accepts arbitrary keys as parameters, with arbitrary types