The code generated by protoc seems to go to great lengths to make sure
that once a message object is created, it can't be modified. I'm
guessing that this is to avoid cycles in the object graph, so that the
serialization routine doesn't have to detect cycles. Is this
correct? Would a cycle in
On Apr 23, 1:03 pm, Kannan Goundan kan...@cakoose.com wrote:
The code generated by protoc seems to go to great lengths to make sure
that once a message object is created, it can't be modified. I'm
guessing that this is to avoid cycles in the object graph, so that the
serialization routine
In many ways this is an implementation detail, though. protobuf-net
takes the other (mutable classes) approach - and indeed one
consequence is that it needs to be careful about loops when
serializing. That needn't be too invasive, though: I simply track the
depth, and don't even bother tracking
You're specifically talking about the Java implementation. We quite
intentionally chose to make message objects completely immutable. Version 1
of protocol buffers (never released publicly) used mutable objects, and we
found it lead to many bugs as people would modify messages that were
The reason I'm asking all this is that I'm implementing a data
serialization format that has the same usage model as protocol buffers
(i.e. generate language bindings, serialize/deserialize).
For me, the biggest benefit of immutability here is that it prevents
cycles in the object graph. (Well,
