Skip to content

Commit c3ad919

Browse files
committed
Enhance README code fragments
1 parent 0424c78 commit c3ad919

1 file changed

Lines changed: 20 additions & 12 deletions

File tree

README.md

Lines changed: 20 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,7 @@ rely on positional order or nested netstrings to convey semantics or encapsulate
6565
To demonstrate the benefits of "keyed" netstrings, say you want to encode Name, Age,
6666
Country and Height as netstrings to be transmitted to a remote service? With standard
6767
netstrings you'd have to agree on the positional order for each value, say netstring #0
68-
for Name, #1 for Age and so on.
68+
for Name, netstring #1 for Age and so on.
6969

7070
Here is what that series of netstrings looks like:
7171

@@ -77,17 +77,17 @@ is to convey a zero length string or a NULL.
7777

7878
With "keyed" netstrings the values can be presented in any order and optional (or NULL)
7979
values are simply omitted.
80-
In the above example if we assign the "key" of 'n' to Name, 'a' to Age, 'c' to Country and
80+
In the above example if we assign the "key" of 'n' to Name, 'a' to Age, 'C' to Country and
8181
'h' to Height the series of "keyed" netstrings looks like:
8282

83-
"5:nName,4:aAge,8:cCountry,7:hHeight,"
83+
"5:nName,4:aAge,8:CCountry,7:hHeight,"
8484

8585
and if Age is optional the series of netstrings simply becomes:
8686

87-
"8:cCountry,7:hHeight,5:nName,"
87+
"8:CCountry,7:hHeight,5:nName,"
8888

89-
Note the change of order as well as the missing 'a' netstring?
90-
All perfectly acceptable with "keyed" netstrings.
89+
Note the change of order as well as the missing 'a' netstring? All perfectly acceptable
90+
with "keyed" netstrings.
9191

9292
To gain the most benefit from "keyed" netstrings, the usual strategy is to reserve a
9393
specific key value as an "end-of-message" sentinal which naturally is the last netstring
@@ -128,32 +128,40 @@ This code fragment encodes a message into a bytes.Buffer.
128128
enc.EncodeInt('a', 21) // Age
129129
enc.EncodeString('C', "Iceland") // Country
130130
enc.EncodeString('n', "Bjorn") // Name
131+
enc.EncodeFloat32('h', 1.73) // Height
131132
enc.EncodeBytes('z') // End-of-message sentinel
132-
fmt.Println(buf.String()) // "3:a21,8:CIceland,6:nBjorn,1:z,"
133+
fmt.Println(buf.String()) // "3:a21,8:CIceland,6:nBjorn,5:h1.73,1:z,"
133134
```
134135

135136
And this fragment decodes the same message.
136137

137138
```
139+
var k netstring.Key
140+
var v []byte
141+
var e error
142+
138143
dec := netstring.NewDecoder(&buf)
139144
k, v, e := dec.DecodeKeyed() // k=a, v=21
145+
_ = k; _ = v; _ = e // Ensure fragment compiles
140146
k, v, e = dec.DecodeKeyed() // k=C, v=Iceland
141147
k, v, e = dec.DecodeKeyed() // k=n, v=Bjorn
148+
k, v, e = dec.DecodeKeyed() // k=h, v=1.73
142149
k, v, e = dec.DecodeKeyed() // k=z End-Of-Message
143150
```
144151

145152
The message is more conveniently encoded with Marshal() as this fragment shows:
146153

147154
```
148155
type record struct {
149-
Age int `netstring:"a"`
150-
Country string `netstring:"c"`
151-
Name string `netstring:"n"`
156+
Age int `netstring:"a"`
157+
Country string `netstring:"C"`
158+
Name string `netstring:"n"`
159+
Height float32 `netstring:"h"`
152160
}
153161
154-
var buf bytes.Buffer
162+
var buf bytes.Buffer
155163
enc := netstring.NewEncoder(&buf)
156-
out := &record{21, "Iceland", "Bjorn"}
164+
out := &record{21, "Iceland", "Bjorn", 1.73}
157165
enc.Marshal('z', out)
158166
```
159167

0 commit comments

Comments
 (0)