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. jonesmichael.jo...@gmail.com <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.
