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.
16 lines
475 B
Plaintext
16 lines
475 B
Plaintext
# Whitespace-significant twin of testdata/basetx.zap.
|
|
# No braces, no @N offsets: blocks are opened by indentation and field
|
|
# byte-offsets are auto-assigned from each type's slot width. Desugars to
|
|
# the SAME brace source as basetx.zap and must generate identical Go.
|
|
|
|
package xvm
|
|
|
|
type id32 = bytes_fixed[32]
|
|
|
|
struct BaseTx
|
|
NetworkID u32
|
|
BlockchainID id32
|
|
Outs list<TransferableOutput>
|
|
Ins list<TransferableInput>
|
|
Memo bytes
|