On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam <jbamster...@gmail.com>
wrote:
> The encoding scheme is described briefly in the README[0] and the code[1].
>
> To answer your two specific questions, interfaces are represented as a
> pair (typeNumber, value) where typeNumber maps to a registered type. (Like
> gob, types must be registered.) Structs are represented as: startCode
> (fieldNumber value)* endCode. The field numbers are assigned by the
> generator.
>
It might be good to be more explicit about how the field numbers are
assigned. From a brief experiment, it seems like there's not a deterministic
relationship between a struct and its wire representation, and instead the
generated field numbers are taken from the generated code file
when it's present. So ISTM that any user of this must be very careful to
preserve that file, and realise that it's not OK to generate
the codec code for a type independently.
I'd also suggest that it would be good to fully document the syntax and
explain the trade-offs of this format and when
it might or might not be appropriate to use.
One other question: how are the type numbers maintained as stable entities
over time?
cheers,
rog.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJhgaciaEnx8r7169%3D8f9YPpFav9JmGf0wc%2BwGZEx72NTTO8tQ%40mail.gmail.com.
