There is certainly no reason why pointer semantic meaning cannot be
supported in encode/decode tools for Go. It does not seem hard to do, but
there was a choice not to do it. I shared my understanding of the reason,
but that's not a suggestion of difficulty or impossibility.
The most natural
Yes, when using pointers and cycles you need to either use ids in the encoding
or break the cycle by dropping the cyclic fields (for example, a simple
‘parent’ field causes an infinite cycle so drop it and make it implicit)
> On Mar 26, 2019, at 2:27 PM, Thomas Bushnell, BSG
> wrote:
>
> I
I mean, everything except the things that are not pointers.
On Tue, Mar 26, 2019 at 2:45 PM Robert Engels wrote:
> This is not really true. In Java everything is a pointer (reference) and
> has no problem with the semantics of passing a reference, it is built into
> the serialization. They may
On Tue, Mar 26, 2019 at 12:45 PM Robert Engels wrote:
>
> This is not really true. In Java everything is a pointer (reference) and has
> no problem with the semantics of passing a reference, it is built into the
> serialization. They may be in fact passed as a pointer (local rpc) or passed
>
This is not really true. In Java everything is a pointer (reference) and has no
problem with the semantics of passing a reference, it is built into the
serialization. They may be in fact passed as a pointer (local rpc) or passed as
a copy of the object graph, or something in between (custom).
When we think of pointers as what they literally are, an address to a space
in memory, it sounds reasonable for Gob to not support them. Things get
more unclear when we consider that, in practice, Go programmers often use
pointers as a replacement for option types. Without pointers, I don't know
To be clear here as educators, it is important to point out that exporting
/ persisting / sending a pointer is an awkward concept.
The normal meanings of sending data beyond an executing program have no
direct use for the pointer’s literal value; “the thing at location 12345 in
the memory of a
On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote:
> Thanks for the reply, Sameer.
>
> Being able to directly send go types is a really big plus for me, I wonder
> if I really want to use gob, are there any recommended rpc choices?
>
Note that gob has at least one significant limitation when
-nuts
Subject: Re: [go-nuts] Question regarding gob
Gob is supported, but I'm not familiar with its current popular use cases. Most often I see people mapping Go types directly to JSON, but using protos with gRPC and other places where the compact encoding helps.On Mon, Mar 25, 2019 at 9:45 AM Glen
Gob is supported, but I'm not familiar with its current popular use cases.
Most often I see people mapping Go types directly to JSON, but using protos
with gRPC and other places where the compact encoding helps.
On Mon, Mar 25, 2019 at 9:45 AM Glen Huang wrote:
> Thanks for the reply, Sameer.
>
Thanks for the reply, Sameer.
Being able to directly send go types is a really big plus for me, I wonder
if I really want to use gob, are there any recommended rpc choices?
Btw, since grpc + protobuf is the recommended choice right now, does that
mean gob is semi deprecated (or at least on
With gRPC, I recommend you use protobuf.
On Mon, Mar 25, 2019 at 8:18 AM Glen Huang wrote:
> I planed to use net/rpc with gob, but then found the GitHub issue saying
> net/rpc is deprecated, and people should be using grpc instead.
>
> That leads to the question should I use grpc with gob or
I planed to use net/rpc with gob, but then found the GitHub issue saying
net/rpc is deprecated, and people should be using grpc instead.
That leads to the question should I use grpc with gob or stick with
protobuf? Google suggests not many people talk about using grpc with gob,
any there
13 matches
Mail list logo
