New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
encoding/gob: allow types to implement an interface which lets them convert themself into an encodable value #48894
Comments
I don't see how that would solve your problem oh punters? |
Why can't your Note that encoding/gob also checks for the |
My type could convert itself to an encodable value and use gob to
encode that, but that requires writing extra code and creating both a
bytes.Buffer and a gob.Encoder every time an instance of that type
would be encoded, when we could just use the existing encoder.
…On 10/9/21, Ian Lance Taylor ***@***.***> wrote:
Why can't your `GobEncoder` method use encoding/binary if appropriate?
Note that encoding/gob also checks for the `encoding.BinaryMarshaler` and
`encoding.TextMarshaler` interfaces.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#48894 (comment)
|
I guess it's not clear to me why you want to use gob to encode a value that is already being encoded by gob. Can you give a specific example of a data structure that would use this new feature? Thanks. |
One situation it would be useful is when you have a struct with
unexported fields and you want to be able to serialize it but you
don't want to make the fields public. I have a few of those, and just
converting it into a new unexported struct at serialization time would
be nice, instead I've had to manually encode / decode the fields and
I've gotten it wrong a time or two.
Another time this feature would be useful is when the struct cannot be
serialized properly as it is and you need to change some fields or
just run some code in general at serialization time. You can still
encode the value by using GobEncode, creating a buffer, attaching a
Gob.Encoder to it and pushing the changed value through, but that
seems inefficient.
One example is my Timer struct. It lets me check if a certain amount
of time has elapsed and to do something if it has, for example
printing "hello" every 2.5 seconds. And I want to be able to serialize
and deserialize it, but I can't because it uses a time.Time to
remember the last time it triggered and if I serialize and later
deserialize it, for example while saving and loading a game, that time
value will be relative to when it was saved, not when it was loaded. I
fixed this by implementing the GobEncode and GobDecode interfaces, but
it would be nice to have a better way.
…On 10/12/21, Ian Lance Taylor ***@***.***> wrote:
I guess it's not clear to me why you want to use gob to encode a value that
is already being encoded by gob.
Can you give a specific example of a data structure that would use this new
feature? Thanks.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#48894 (comment)
|
Seems like we already have a way of doing this (GobEncode or BinaryMarshaler or TextMarshaler), |
Currently, the encoding/gob package provides the ability to change the way a type is serialized or deserialized by implementing GobEncoder or GobDecoder on it. This works by having the type somehow convert itself from or to a byte slice and then gob just serializes the resulting bytes.
This isn't usually a problem, but some types can't be serialized as they are and require using the encoding/binary package or something similar to manually convert them to bytes and back again.
This approach is also problematic when trying to serialize a data structure that contains multiple pointers pointing to the same value. When serializing, gob will store the values behind the pointers, not the pointers themselves, and then later loading the data could cause unexpected effects.
A much nicer approach would be to add two new interfaces that allow their implementers to return values which should be serialized in their place and to convert back to the original type respectively.
I'm not sure what the names for these interfaces should be.
The text was updated successfully, but these errors were encountered: