Comment #8 on issue 120 by ken...@google.com: 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
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
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at