--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscribe@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
On Oct 7, 2016, at 9:54 AM, 'Adam Cozzette' via Protocol Buffers <prot...@googlegroups.com> wrote:Here's the thing, though: we are actually thinking about removing the MessageLite::GetTypeName method at some point in the future. Lite protos are intended primarily for mobile and so in that environment it's important to keep the binary as small as possible and also avoid including symbols in the code that's distributed, whereas currently that method requires us to generate code that includes the message type names. So I think it would be best to avoid creating another dependency on that GetTypeName() method when it might be going away in the future.
Thanks for the info.I feel like without pack/unpack/Is method, the utility of Any will diminish. For example, the rpc status proto (https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto) uses repeated Any field. It'd not be possible to write code like one described here - https://developers.google.com/protocol-buffers/docs/proto3#any because you won't know if it is safe to convert value to a give message. I also came across this post after my post which marks the request as a bug currently - https://github.com/google/protobuf/issues/1974
Regarding the future of GetTypeName, though it has overhead, feel like it could have many utilities outside of the Any support as well. I don't have concrete use case in mind though as I am just starting on protobuf. This brings another important question that I was wondering if somebody already has data around. There are two options for reducing code bloat. One is Lite and another is code_size. I understand that lite reduces code bloat by removing descriptors/reflections related code (thereby reducing the library size) and code_size reduces the code bloat by generating less code per message but puts descriptors/reflectors back in(shared code). And the recommendation is to choose code_size option if number of message are much higher compared to the overhead caused by the size of lib. Are there any benchmarks around what the size of the library is (and lite version) and what is the per message overhead saved by the code_size option? And the performance drop with code_size option?
--