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/CAEkBMfGo%2BWUdo41D_DuY6%3DeRRNtts9O-cvHttf%3Dz%2B-HzYtgvdA%40mail.gmail.com.
