Thanks for the suggestions. I created https://github.com/jba/codec/pull/1 to address them. You can comment in more detail there if you'd like.
On Wed, Jan 20, 2021 at 12:13 PM roger peppe <rogpe...@gmail.com> wrote: > 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/CAEymQsQ%3D4WkteR1t6o5TXfzp0egR%3DvsGii8On_mKBU%2B_YRM%2BfA%40mail.gmail.com.
