On Thu, Aug 15, 2019 at 11:14 AM Jochen Voss <jochen.v...@gmail.com> wrote:
> You are right. But the type is somehow represented by some index or so, > instead of the name? Since the type needs to be registered using > gob.Register() beforehand, this seems not totally impossible to me. > `Register` only gets the type-name though. It somehow would have to reproducibly map from type-names to indices and back for this to work - the process doing the *decoding* isn't necessarily the same process doing the encoding (that's kind of the point :) ). So AIUI, the name still needs to be present. The documentation <https://godoc.org/encoding/gob#hdr-Encoding_Details> says so too: Interface values are transmitted as a string identifying the concrete type > being sent (a name that must be pre-defined by calling Register), followed > by a byte count of the length of the following data (so the value can be > skipped if it cannot be stored), followed by the usual encoding of concrete > (dynamic) value stored in the interface value. (A nil interface value is > identified by the empty string and transmits no value.) Upon receipt, the > decoder verifies that the unpacked concrete item satisfies the interface of > the receiving variable. I wish I could help more :) I'd be interested to see how you get this resolved though (and maybe someone who used gob more can chime in). AIUI it *should* be possible to do what you want, so once we figured out how, it would probably be super helpful to contribute it as a runnable example. But then, when I change your code to let gob do the encoding itself, the > name is suddenly there: https://play.golang.org/p/Qz7zDKL047z, so > probably the absence of the type name is part of the problem. > > >> And I agree that this probably shouldn't panic, but instead return an >> error. But given that the encoded bytes don't contain the name of the >> concrete struct, there is no way the decoder can know where you want to put >> it, without giving it the correct type. >> > > Yes, an informative error instead of the hard to interpret panic would be > nice. I wonder whether this is indeed intended behaviour, or whether this > is some kind of bug in the encoding/gob package. > > -- > 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/32c27653-c50b-42cd-a525-8c9e9298bf60%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/32c27653-c50b-42cd-a525-8c9e9298bf60%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfF9nv70UpS4VF8imVDpSANBpeP4Z_tkkiTECje7d8f16Q%40mail.gmail.com.
