Implement a ref system similar to JSON schema and OpenAPI. Users can specify a ref by name, and, when used, we'll look it up, in both the main tspec and in a separate .components (or maybe .schema or something similar) section of the tspec. Among other things, this would be extremely convenient for #232.
Implementation of this is almost certainly easier if we convert the tspec object to S7, with things created via tib_ref() returned dynamically through a getter.
The named ref doesn't have to exist when the tib_ref() is initialized, making construction easier than if we have to resolve everything at that time.
I imagine the tib_ref() signature looking like this (see #228 for why I dotted all the argument names):
tib_ref(
.key,
.name,
...,
.required = TRUE,
.fill = NULL, # Or maybe this is inherited from the ref? I lean toward it being inheritable, but this overrides
.ptype_inner = ptype_any(), # See #230
.transform = NULL
)
And we'd also add a .components argument to the tspec_*() functions, where users could specify a list of tib_*() specifications or a tspec to use as a lookup table for refs.
I don't think we need multiple levels of .components. When we're translating openapi specs (and, eventually, json schemas), we'd collapse things like "components/schemas/Pet" down to schemas-Pet. OpenAPI technically allows for other types of references, but I think those are very rare, and we can eventually deal with them by following the references once to convert them to the .components object.
refs and components will never be guessed, so theoretically this won't impact guessing. We can likely resolve and "solidify" the tspec before it is passed to C (or possibly "while" it is passed to C, I'll have to look at the implementation more to make sure I understand what makes sense there).
This ticket will almost certainly be implemented over the course of multiple sub-issues.
Implement a
refsystem similar to JSON schema and OpenAPI. Users can specify a ref by name, and, when used, we'll look it up, in both the main tspec and in a separate.components(or maybe.schemaor something similar) section of the tspec. Among other things, this would be extremely convenient for #232.Implementation of this is almost certainly easier if we convert the tspec object to S7, with things created via
tib_ref()returned dynamically through a getter.The named ref doesn't have to exist when the
tib_ref()is initialized, making construction easier than if we have to resolve everything at that time.I imagine the
tib_ref()signature looking like this (see #228 for why I dotted all the argument names):And we'd also add a
.componentsargument to thetspec_*()functions, where users could specify a list oftib_*()specifications or atspecto use as a lookup table for refs.I don't think we need multiple levels of
.components. When we're translating openapi specs (and, eventually, json schemas), we'd collapse things like "components/schemas/Pet" down toschemas-Pet. OpenAPI technically allows for other types of references, but I think those are very rare, and we can eventually deal with them by following the references once to convert them to the.componentsobject.refs and components will never be guessed, so theoretically this won't impact guessing. We can likely resolve and "solidify" the tspec before it is passed to C (or possibly "while" it is passed to C, I'll have to look at the implementation more to make sure I understand what makes sense there).
This ticket will almost certainly be implemented over the course of multiple sub-issues.