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 <tbushn...@google.com> > wrote: > > I mean, everything except the things that are not pointers. > >> On Tue, Mar 26, 2019 at 2:45 PM Robert Engels <reng...@ix.netcom.com> 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 a copy of the object graph, or something in between (custom). >> >> There is no reason Go can not achieve use the same paradigm. >> >>> On Mar 26, 2019, at 11:48 AM, Michael Jones <michael.jo...@gmail.com> wrote: >>> >>> 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 program that ran last year” is not much help. >>> >>> On the other hand, one might imagine pointers being like file names and >>> then recreate both content and references during reading. The export format >>> could persist all the typed, pointed to values in tables, and then for each >>> pointer variable exported send instead advice like “put the address of the >>> 456th element of the table for type C things in this pointer slot.” >>> >>> A persistent format supporting this way of recreating the semantics of >>> pointers is very much like an archive format (Zip) with support for >>> symbolic links. It is not particularly hard to implement, but it is a >>> “heavyweight” approach. My sense is that the common desire in export tools >>> is high speed and byte efficiency so it is natural that Gob and other >>> mechanisms adopt the “pointers don’t make sense for export” argument. >>> >>> Michael >>> >>>> On Tue, Mar 26, 2019 at 6:01 AM roger peppe <rogpe...@gmail.com> wrote: >>>> >>>> >>>>> On Mon, 25 Mar 2019 at 14:45, Glen Huang <hey....@gmail.com> 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 encoding Go >>>> types - it doesn't know about pointers - in general it encodes a pointer >>>> by omitting a field. So if you want to send a slice of a pointer type >>>> where some elements can be nil, you're out of luck: >>>> https://play.golang.org/p/ThVUT_M0hjR >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to golang-nuts+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> -- >>> Michael T. Jones >>> michael.jo...@gmail.com >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
