FAQ
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Kyle Lemons at Feb 26, 2013 at 6:11 am
    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, 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Feb 26, 2013 at 7:36 am
    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

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tracey Brendan at Feb 26, 2013 at 7:38 pm
    Is it possible to write GobEncoderDecoder that is agnostic to the value
    being used that implements those interfaces? It seems like it should be
    possible, or be made possible by saving the nameToConcreteType map.

    Could you elaborate on your point Rob? Do you / the go-dev team not find it
    useful to be able to save a data type to memory so it could easily be
    loaded up again? I don't design servers, so I know I'm not among the core
    userbase, but interfaces and function closures make it very easy to write
    modular code, which I find very useful for my work. I tend to use machine
    learning algorithms which involve training a model, which is usually
    computationally expensive, but one the model is trained, it is cheap to
    evaluate and can used again and again, preferably by different scripts. If
    interface values cannot be saved, then it restricts the modularity that a
    good machine learning package would provide. Another example of the utility
    in saving interfaces is in scientific computing, where codes that can take
    hours or days to run, and having restart files is useful to monitor
    progress and in case the code needs to be terminated mid run. While I only
    have limited experience using the go concurrency models, it was one of the
    things that excited me about the language, and I think that go could find a
    userbase in the scientific community.

    Having spent the last two hours in the internals of the decoding package, I
    can see that you aren't happy with the interface implementation of gob. For
    the specific problem at hand, I think I can call an initialization script
    to set up all the interface types, and then use the gob decoder to fill in
    the rest (or can limit myself to a pre-specified list of things which can
    implement the interface). On the one hand, this will have the benefit of
    saving memory, but it will either prevent decoupling of the model
    generation script and the model using script, or it will prevent me from
    allowing custom reshaper types. I do think the functionality of being able
    to easily save/load arbitrary data would be very useful.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Feb 26, 2013 at 7:44 pm
    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

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steve McCoy at Feb 26, 2013 at 8:08 pm

    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.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tracey Brendan at Feb 26, 2013 at 8:10 pm
    Thanks for the reply.

    It's easy to send the type, rather than the interface value, for example,
    by removing the ampersand in line 27. The problem is decoding it on the
    other end. Is the correct solution to have an initialization script to be
    run on both ends which sets the specific types that are satisfying the
    interface, and then use GobsDecode to populate the elements of that type,
    for example as in http://play.golang.org/p/FQkrB1AiWv ? (I think I know
    what that code is doing)

    By 'functions on a wire', do you mean "porting a function to a different
    caller without the caller knowing what the function is"?

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tracey Brendan at Feb 26, 2013 at 8:29 pm
    Sorry, this is a more illustrative example of what I mean
    http://play.golang.org/p/PyW4a0vF_K

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Feb 26, 2013 at 8:44 pm
    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

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tracey Brendan at Sep 23, 2013 at 6:55 pm
    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

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedFeb 26, '13 at 5:53a
activeSep 23, '13 at 6:55p
posts10
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase