On Tue, Mar 26, 2019 at 12: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).
When you deal with pointers during serialization, you have to deal with the potential of cyclic references. I remember getting frustrated during my Java days with things failing when encoded in JSON where they worked just fine with Java serialization because of cyclic references. This is not a language problem, it is more of an encoding problem. > > 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.
