1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
// The wire format: how a ZD value survives the trip to the store and back.
//
// # The bug this file exists to fix
//
// `JSON.stringify` cannot represent a JavaScript `Map`. It does not throw,
// it does not warn, it returns `{}`:
//
// JSON.stringify(new Map([['ada', 1]])) // → "{}"
//
// A `Map` is what §5.4's `Map of K to V` compiles to — an object would
// coerce every key to a string, which is exactly why it is a `Map` — so
// every `durable Map` wrote an empty object and read nothing back. It
// failed silently, which for a persistence bug is the worst way to fail.
//
// # Why a marker and not an array
//
// `Map` and `record` cannot share an encoding: a record is a plain object
// and a map has to be distinguishable from one, or `decode` cannot know
// which to rebuild. So a map is tagged:
//
// new Map([['ada', 1]]) ⇄ { "$map": [["ada", 1]] }
//
// `$` cannot appear in a ZD identifier — the lexer's rule is
// `[\p{XID_Start}_][\p{XID_Continue}]*`, and `$` is in neither class — so
// no record field can ever be named `$map` and the marker is unambiguous
// by construction rather than by convention.
//
// # What the four shapes look like on the wire
//
// Whole, Decimal number Text string
// Truth boolean empty [] or {"$map":[]}
// List of T array record object, fields by name
// Map of K to V {"$map":[[k,v]]} choice {tag, fields}
//
// A choice is `{ tag, fields }` (see `variant` in `dom.js`) and a record is
// a plain object, so both ride as ordinary JSON objects and recurse.
//
// # One definition, three users
//
// The browser encodes a request body, the adapter decodes it and encodes
// what it stores, and the live-sync stream carries the encoded form
// straight through. Three places, one file — a second copy of these rules
// anywhere is how the two halves come to disagree about what `{}` means.
//
// # Why `encode` consults `toJSON`, and why it is not a second marker
//
// `encode` runs *before* `JSON.stringify` and hands it a value that has
// already been walked. That is what makes the `$map` marker possible, and
// it also means `JSON.stringify` never sees the original object, so every
// `toJSON` in the program was silently defeated, and any type that grew one
// later would have been defeated the same way.
//
// It cost this once already. `append` compiles to a chain of links rather
// than to an array, because appending has to be O(1) or a builder is
// quadratic, and the class carries a `toJSON` that flattens the chain for
// exactly this trip. `encode` walked past it: a link is not a `Map` and
// `Array.isArray` is false for one, so it fell through to the record branch
// and a durable `[1]` was stored as `{"base":[],"item":1,"flat":null}`
// (#204).
//
// The narrow fix would have been a third branch that recognises the link
// class. It was rejected: the mistake is not that this file does not know
// about `append`, it is that walking structurally overrides what a value
// says about its own JSON form, and a third branch leaves that true for the
// fourth type. So `toJSON` is consulted generally and first, which is the
// rule `JSON.stringify` itself follows, and a type that has an opinion
// about its JSON form now gets it honoured at both layers instead of one.
//
// This does not weaken the `$map` marker's argument. A `Map` has no
// `toJSON`, which is the whole reason this file exists, so nothing about
// how a map rides has changed.
/** A ZD value as JSON-representable data. */
export
/** The inverse. */
export
// $dev
/**
* Assert `encode` left nothing `JSON.stringify` writes as `{}`.
*
* **This checks #204's family rather than its instance.** The bug at the
* top of this file was a `Map` reaching `JSON.stringify`, which does not
* throw and does not warn: it returns `{}`, so a `durable Map` wrote an
* empty object and read nothing back. `encode` fixes that for `Map`, and
* since the `toJSON` change for a type that declares its own JSON form.
* What neither fixes is the *next* type with the same property, and no
* static pass anywhere would see it — the value is a JavaScript object
* either way.
*
* So the invariant is checked instead of the case: after `encode`, every
* object left is an array or a plain object and every leaf is a JSON
* scalar. A `Map`, a `Set`, a `Date` or any class instance that does not
* declare a `toJSON` fails here, naming the path to itself, instead of
* silently becoming `{}` in somebody's store.
*
* Development only. A release build runs `JSON.stringify` against the same
* encoded value with no check in front of it, which is what it has always
* done.
*
* The walk is a worklist rather than recursion, and that is not a style
* choice: `encode` is already recursive, and a second recursion over the
* same value doubles the stack a nested value needs. `wire_fuzz.rs`
* generates values deep enough that it does not fit, so an assertion
* written the obvious way would fail on values the format carries.
*/
export
// $end
/** A ZD value as the JSON text that crosses the wire. */
export
/** JSON text back into a ZD value. */
export