Re: [golang-dev] Add an example to gobs for encoding / decoding interfaces

[Kyle Lemons]

Register is required on the decode side, so registering on the encode side isn't doing quite what you think it's doing.  Typically register is done at init-time for types that you know will need to be stored in interfaces on receive.

On Mon, Feb 25, 2013 at 9:06 PM, <tracey....@gmail.com> wrote:

I was hoping you could add an example for using Gobs with interfaces to either the golang.org/pkg/encoding/gobs or the gobs-of-data blog post. An example like

http://play.golang.org/p/zdanYxcZB_ shows that you can add the types to the register without listing them specifically (as the code from issue 3568 does), and shows that you need to add a pointer to the interface to encode, rather than add the interface value itself.

If this is not the right place to post this, let me know

--
 
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rob Pike]

Also although they is supposed to work, and can be made to work when
used properly, interfaces are not gob's strongest feature. If the
package needs examples, which it might, the only one there should not
be about interfaces. There must be more examples about simple data,
which is what it is best at.

If I could roll the clock back, I'd take interface support out. It was
a mistake to add them (I had my reasons, but they didn't pan out.)
They're expensive and clumsy and confusing yet overused. But they're
here to stay.

-rob

[Rob Pike]

The problem is one of intended use. I intended the interface support
to be a rarely-used thing, developed with a specific application in
mind, allowing one to transport a behavior across the network. But
people see it, think 'interface{}', and use the mechanism to avoid
thinking about types on the wire, treating it as a sort of generic
Object. It's just lazy, and it's very expensive to do this, since
every interface value needs a type string along with it, and it
interrupts the stream flow.

Used well, gobs can be efficient. You send a stream, not a value, and
you send repeated items of a defined static type, not a one-off. The
interface support violates both of those conditions.

Instead of sending interfaces all over, send concrete data types when
possible. They're much more efficient and lead to better design. If
you're sending interface{} using gobs, you're doing it wrong.

And functions on the wire: they'll never work, not this way anyway.
Try Erlang instead.

-rob

[Steve McCoy]

On Tuesday, February 26, 2013 2:43:59 PM UTC-5, Rob Pike wrote:

And functions on the wire: they'll never work, not this way anyway.
Try Erlang instead.

-rob

Even Erlang has limits on that: The function has to be already defined on the other node if it tries to call the function, or an exception will be raised. They basically send around portable references to functions.

[Rob Pike]

If you exported those types (reshaper, neuron, etc.) then at first
blush the code looks like it should work without a custom gob codec.

If you're sending a lot of reshapers, though, it might be more
efficient send a struct with a discriminator, a hand-built union if
you like. Gob won't send the field that's not set.

type Union struct {
Which int
Type1 *type1
Type2 *type2
...
}


-rob

[tracey....@gmail.com]

Sorry to dreg up this old thread, but I punted on the issue for a while, and it has come back again.

My use case is a little different than a server case; I'm using gobs to save a structure to disk so that it can be loaded up again in a future program. There won't be many programs sent over the wire, it'll be once at the end of the code, and once at initialization (probably). The data structure I'm trying to save can be customized through the use of interfaces. My thought is for my struct to encode the interfaces (which may or may not have private data and be GobEncoders), and also to decode them. While this will add some extra bytes, it will also allow error checking when the struct is loaded to ensure that the data has been initialized like it was saved (with the same interface values, etc.). Is this a blanketly bad use of gob, or does it depend on the situation? Should my data structure just encode its own private data and require the user to append their own interface data? This would make my package less easy to use, but it sounded from your above comments Rob that what I am planning is bad policy.

I can move this discussion to golang-nuts if that is prefered.

Thanks