Oh, I should also not, to be fair: You *can* decode the gob into an `[]Dimension`, but you *can't* do the same with json. So, the comparison with json is unfair insofar, as the encoded json is actually incomplete - it doesn't hold the type-information of *which* `Dimension` implementation to use.
On Sun, Apr 4, 2021 at 5:18 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > I believe it is expected behavior (well… given that the gob format is > pretty much defined as "whatever the gob package does", it surely is, at > this point). > gob is able to decode types completely, without having a "framework" to > work on - you need to pass a pointer to `json.Unmarshal`, so that the > decoder knows what you expect, but that isn't necessary with gob. It does > that by encoding interfaces using their type-name, followed by their value > and then looking up the type-name when decoding (which is why you have to > `gob.Register`). Note that a `[]Dimension` *can* be heterogenous, that is, > it doesn't have to contain only one type of value. If you look at a hexdump > of your data, you'll see that's what's happening - every point gets a > `main.Point` in the output. > > You are correct, that gob is not super efficient in this case. There > probably would be a denser packing (where, instead of a type-name, you use > an index into an implicit table, for example). But at this point, it's just > how gob works. I said it before and I say it again: I don't believe gob is > a very good encoding format. It is convenient to use, in Go, but IMO it > also comes with significant drawbacks. You might want to look into, say, > protobuf. > -- 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/CAEkBMfF1cA9_QRB8BTKiO8zqfV%2Bjz-ZRQ67ZJrujOArBH5W9yw%40mail.gmail.com.
