On Sat, Jan 30, 2010 at 3:03 PM, Jacob Rief <jacob.r...@gmail.com> wrote:
> > Please just don't add anything new. If you are unhappy with what
> > ZeroCopy{Input,Output}Stream provide, you can always just create your own
> > stream framework to use.
>
> Well, I have to live with that decision. Maybe in the future some
> other people have similar use cases. Maybe in version 3?
>
I don't think this is that bad. The ZeroCopyInputStream interface was
really designed to be an adaptor for using other streaming frameworks with
ProtocolBuffers. It's not meant to be a streaming framework in itself --
that would be outside the scope of the library. So, I'd rather keep the
interface as minimal as possible, providing only what is strictly necessary
for protocol buffers to operate. I don't think Seek() or Reset() are
strictly necessary, and since it's not clear to me that either one is
necessarily "correct", I'd just rather not get into it.
> Just for curiosity, the protobuf code is really easy to read and to
> understand. The only thing is disliked is the mapping of class names
> to filenames. Is all the code inside Google written that clearly?
>
Thanks! I don't know if I can give an unbiased answer to this question,
since I wrote most of the proto2 code, so of course to *me* it is the
clearest code in all of Google. ;) I think in general the code here tends
to be pretty high-quality due to our policy of reviewing every change
pre-checkin. However, there is certainly some ugly code, mostly code which
evolved slowly over time with many different authors.
If you want to find out for yourself, we're hiring! :)
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@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.
