[macros] Add dart_model proposal. #3893
Conversation
|
Hi @jakemac53, an attempt to put an actual proposal in writing re: dart_model, nothing really new but including the idea that we go with JSON schema + JsonBuffer per my experiments. Lots to discuss I'm sure :) |
|
|
||
| Each schema is available in two versions: a "strict" schema that only matches what the current package produces, and a "loose" schema that allows for future changes. | ||
|
|
||
| Schemas are versioned using semver. Schemas are updated in place for compatible changes, and as new files for major version (incompatible) releases. |
There was a problem hiding this comment.
How exactly does this interact with the strict vs loose formats?
This package will also be used as a part of SDK binaries, which will not take into account the current users package version, how does that affect things?
There was a problem hiding this comment.
Good questions.
I'm not currently envisaging using the schemas in any online way; so far I've only considered using them for testing--check that we think we comply with the schema--and for codegen, generate classes that match the schema. So this was mostly a guess about what would be useful.
I already found having the schemas embedded in Dart useful in testing, so that's why I mention it.
Re: the client package version, I guess we send it on the wire at some point.
|
|
||
| Data types can be serialized to and from JSON per their schemas. | ||
|
|
||
| A binary serialization format is available for performance. When this is used, values are accumulated directly into a binary buffer, so there is no "serialize" step. The received of the value can use values directly from the buffer, so there is no "deserialize" step. |
There was a problem hiding this comment.
Does this binary format use String keys, a specified ordering, or something else?
There was a problem hiding this comment.
The POC I hacked together is pretty much a byte buffer representation for nested Map<String, Object?>, I like this direction, it should mean we can implement something once and use it without changes as the JSON evolves. It's not a design yet though, just "I think we can model as JSON and still do something fast underneath".
|
As a high level doc of the concept this LGTM. Would be great to build on this and discuss how exactly it should be used for macros though, how/when exactly diffs should be pushed, how/if this interacts with phases (or rounds), how references to specific objects should be sent back to the compiler, etc. |
|
Thanks! Yes, a description of the higher level protocol on top is something we need; as well as next steps for bootstrapping some kind of package:dart_model within the current setup. Let's chat tomorrow :) |
For #3872 #3706