Comment #7 on issue 120 by owen.oma...@gmail.com: Request to allow extending CodedInputStream and CodeOutputStream
http://code.google.com/p/protobuf/issues/detail?id=120

I understand about not wanting to get locked into an API, although I'm sure you'll already find that if you change the Coded*Stream API you'll break many users. It is already part of your public API and you'll need to deprecate old methods and gradually move your interfaces if you want to make changes. I certainly do understand that inheritance is a brittle dependency, which is why I separated out the interface from the implementation, but fundamentally I'm looking to replace the serialization black box with a different implementation, so it is the right abstraction.

What benchmarks would you want to see? Writing and reading a million objects from a file stream?

I hadn't considered creating a custom protoc plugin and that is an interesting thought. It is a lot more involved than just implementing the two classes and naively seems more dependent on the protobuf internals. It would also mean that the generated classes would be twice as large with both my serialization code and the original serialization code.

--
You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to