Additional access to schema/dmt package; schema concatenation feature #483
Conversation
This is both necessary and sufficient to make it feasible for someone to easily manipulate schema DMT data as IPLD, using the IPLD libraries. That's a fairly obvious win. (If I had my way about the language of golang, I'd be able to do this while also keeping it strictly immutable. That's... not how it works, unfortunately. But as it's normal in golang to have package-scoped vars with semantic rules about no-touchy and no actual compiler-enforced support, then, we might as well not deny ourselves useful things by wishing for support for stricter rules that just doen't exist.)
This stops one step shy of introducing an "include" features to th IPLD Schema syntax... but can easily be used to produce such behavior.
| // of the result yet; you'll need to apply `Compile` on the produced value | ||
| // to produce a usable compiled typesystem or to become certain that | ||
| // all references in the DMT are satisfied, etc. | ||
| func ConcatenateSchemas(a, b *Schema) *Schema { |
There was a problem hiding this comment.
would be great to have a basic test/example so that there's an ongoing validation that concatenation of two basic schemas works
There was a problem hiding this comment.
In general I'm pro-testing but in this case I don't know what would provide useful coverage in exchange for the additional volume of test code. We really are just essentially conjoining two maps here.
If there were more interesting and complex logical operations here, I would certainly want to test it, but what this does is so trivial I don't know if it's worth it.
…pes. This is technically a breaking change, as it's an exported name, but I don't think there are references to this value outside this repo to date.
warpfork
force-pushed
the
schema-concatenation
branch
from
7b9cc26
to
c68ba53
Compare
|
Worth mentioning that I see this as an experiment-enabler moreso than a feature we'd want to spotlight. It'll be sufficient for me to start playing with what a UX of schemas split across multiple files would feel like, in a downstream repo, without pushing any opinionations about that into this repo where they'd become a maintenance commitment. (Then, I can start taking notes on the experiences that produces, and bring those around for any future discussions about making this a more broadly supported and defined feature of the schema system.) I'm intentionally refraining from going any further than that at this time. |
|
I'll hope that this experiment leads to a more full-fledged feature in the future, and meanwhile, if it breaks, yep, it'll be me who regrets it. Fair nuff. |
|
@warpfork we're now getting failures while trying to use the latest master because the new doc.go has |
|
Oof. That was not from this PR, but was my bad for thinking I could push a docs change without waiting for testing 😓 I believe I've fixed it again now. |
This is a small diff which introduces a bit more ability to introspect and operate on
schema/dmtdata.Making the type system accessible makes it easier to manipulate the schema DMT as IPLD, which is a very neat thing to be able to do. (Some of this is already possible because
schemadmt.Type.Schemais exported specifically; but I see no reason not to export the entire typesystem.)Then, a function is introduced which can conjoin two parsed schema DMT documents. (This stops just shy of introducing an "include" syntax to IPLD Schemas, but one can see how it could easily be involved in producing such a feature.)