a shallow copy, ready for one field to be overwritten.
The reverse of fetchStructModule: given an application value's
own class, finds the schema name it was registered under (if
any) — what lets automatic encode-time validation recognize a
plain JS class instance as "this is a Foo" without being told so
explicitly.
Looks up a compiled schema by struct name, consulting the lazy resolver (if any) on a miss and caching the result. Whether schemas are all compiled up front or resolved on demand (a resolver reading a file, calling a schema service, ...) is entirely the caller's choice — this is what makes both paths look identical to everything else, which never needs to know which one is in play.
Declares which JS class a schema's data is expected to be — used
only for {:reference, name} checks during encode-time
validation. Decode-time reference checks don't need this: they
carry an internal provenance marker regardless of materializer
shape (schema/validated.cjs).
The reverse of putTag: registers how to turn an application
value (keyed by its constructor) back into @name value on
encode — decode-side dispatch happens by wire tag name, encode
needs to dispatch by JS class instead, so the two directions need
separate tables.
Marks (or unmarks) this registry as decoding a trusted source —
the default. Currently the one thing this affects is keyword:
trusted (the default) decodes it as a real, global Symbol.for;
untrusted decodes it as DXNKeyword instead, so no decode path is
ever forced through the global symbol registry's own
never-garbage-collected interning for attacker-controlled text.
symbol is deliberately unaffected either way.
Fileoverview
Extension point for both
structandcustom-tagdecoding/encoding, mirroringDextrin.Registry. No entry for a given name → decode falls back to an opaqueDXNStruct/DXNCustomTag— never a hard failure, since neither type requires a registration to be representable at all.Struct entries only ever come from a compiled
.dxnsschema (schema/compiler.cjs) plus an optional materializer layered on top — there is noputStructthat hand-writes a struct's shape directly, becausestructis schema-dependent by design: the schema supplies field names/order/types, a materializer only decides what nicer decoded shape to produce from an already-schema-validated field map.Registryinstances are plain, immutable-by-convention data — everyput*method returns a newRegistry, never mutatesthis— threaded explicitly throughdecode/encode/schema.compile, never a global or a class with hidden state.