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 implementation uses a map in both the encoder and decoder.
The least memory way uses the existing pointer values as the instance ID. A
refinement uses 2x map memory but is more compressible in the wire format.
encoder:
if next item is a pointer{
is pointer NOT in the map of previously sent pointers?
recursively encode/transmit *pointer and use uintptr(pointer) as its
ID.
send "next thing is a pointer to a T; value is whatever you
(reconstructor) generated for ID uintptr(pointer)"
}
decoder:
opposite of this, where the map has IDs sent and pointers to locally
allocated objects.
That is all it takes. More suave is to have the map not just be a
map[uintptr]struct{} but of map[uintptr]uint64, where the ID is a serial
number counting up. This would be invisible to the decoder, but real
addresses sent as IDs will be big numbers in a 64-bit address space and
take more bits to encode than one byte 0..255, two byte 256..65535, ...
On Tue, Mar 26, 2019 at 3:44 PM Robert Engels <reng...@ix.netcom.com> wrote:
> 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. 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.
>>
>
--
*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.
