mirror of
https://github.com/zap-proto/py.git
synced 2026-10-30 15:04:09 +00:00
zeekay
b51be46fa8
The whitespace-significant .zap schema is the estate's default form, but
Python could not read one at all — bindings had to be written by hand, which
is how two runtimes start disagreeing about what a schema means.
zap.schema reads it the same two steps as zap-proto/go's cmd/zapgen: desugar
rewrites the whitespace form into the canonical brace form (a near-identity
that only ADDS the {}/@offset tokens the brace grammar requires, so a brace
file round-trips byte-for-byte), then one parser handles both styles. Field
offsets come from the same slot widths, so both runtimes lay a schema out
identically.
emit renders one module per schema: zero-copy views over zap.wire (wrap
parses, properties read fields in place at their schema offsets, build
writes) and, per interface, an ordinal enum, a handler Protocol, a dispatch
function and a typed client. Channel and CallFailed move into zap.pipeline,
where the RPC model already lives, so a generated module declares only the
schema's own names.
Pinned against Go two ways: the desugar cases are cmd/zapgen/desugar_test.go
verbatim, and the generated Ping.build / BaseTx.build must reproduce the
bytes Go's own generated bindings write. Across the 263 unique .zap files in
the estate the two generators agree on accept-or-reject for every one.
15 lines
388 B
Plaintext
15 lines
388 B
Plaintext
# Test schema for the zapgen golden test.
|
|
# Matches the canonical example in the zapgen spec.
|
|
|
|
package xvm
|
|
|
|
type id32 = bytes_fixed[32]
|
|
|
|
struct BaseTx {
|
|
NetworkID u32 @0
|
|
BlockchainID id32 @4
|
|
Outs list<TransferableOutput> @36
|
|
Ins list<TransferableInput> @44
|
|
Memo bytes @52
|
|
}
|