Updated: Comment #10
Right now, typed config implements the typed data interfaces but does not properly implements its API. Let's use this issue to work over that and fix things based upon
Regarding the data definitions I mostly see 'mapping' and 'sequence' as problematic, as they are non-valid top-level definition keys. Per-type specific keys are supposed to go below 'settings' and should be documented at the type's class. This could be moved during processing though.
Sequences seems to be equivalent to lists but use a totally different notation. We need to align it with the typed-data list notations. However, I think the way sequences are specified matches with what others suggested doing for typed data as well (and I agree with), so maybe we should re-work it for typed data first.
Issues I see with the current code:
- Used type names, i.e. as returned from getType() have to be registered via the plugin discovery.
The way I see this could work:
- Use the typed config manage to pre-process config schema definitions to valid typed data definitions. That's partly done already, but we need to make sure that we end up with data definitions matching the docs. Also the custom merging of type-definitions and data-definitions as done in the TypedConfigElementFactory right now could happen there.
- Best, this processing of the definition would be available as its own helper function also.
- Make the classes extend the new general Map and List classes as suiting (or not).
- Make sure the classes properly implement the interfaces - I mostly see all validate() implementations violating the interface. Maybe we can re-used typed data tests for the map and ItemList classes.
a patch replacing type 'undefined' to 'any' was propose but the 'undefined' type is in system.data_types.schema.yml