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 imple
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 me
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 b
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
> as
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
ho
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 pro
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 encodi
-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
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 hiat
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 sti
12 matches
Mail list logo
