Comment #8 on issue 120 by Request to allow extending CodedInputStream and CodeOutputStream

It's true that because Coded*Stream are public, we cannot contract these interfaces. However, we *do* currently have the ability to *expand* these interfaces without breaking anyone, whereas with your proposed change this would be considerably more difficult. Moreover, it is much easier for us to change the pattern of calls made by the protobuf implementation *to* these interfaces when there is only one implementation. If there are multiple implementations, we don't know the affect our changes might have.

For an extreme example, imagine if in the future we discover that we can make encoding much faster by generating code which writes directly to CodedOutputStream's underlying byte array rather than calling its various methods. So we add a new method like byte[] getBuffer(), and the encoder now calls only that. Your custom implementation of CodedOutputStream would be thoroughly broken by this, probably requiring a complete re-design and rewrite of your entire project. Since it's hard to tell how many people would be broken by such a change, we'd probably avoid making it in the first place, meaning everyone remains stuck with an inferior implementation.

So, you see, this kind of decision is not as clear-cut as it at first seems. Adding any sort of abstraction to the library requires careful thought and design. If you want to pursue this, you'll probably need to start a discussion thread on the mailing list where you and the protobuf maintainers (which no longer include me) can discuss the pros and cons in more detail.

Regarding benchmarks, I think there are some Java benchmarks in the SVN repo that you can run fairly easily.

You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to