Updates:
Owner: [email protected]
Comment #6 on issue 120 by [email protected]: Request to allow extending
CodedInputStream and CodeOutputStream
http://code.google.com/p/protobuf/issues/detail?id=120
The problem with this is that if we ever modify the API of Coded*Stream
(e.g. to add new methods to support new features), we will have to worry
about breaking people like you who have written custom implementations. In
fact, we might even break you if we merely change the way Coded*Stream is
called, without changing its implementation. Worrying about this creates
obstacles to development.
Also, abstraction has a performance cost which may be particularly acute in
the case of Coded*Stream, which are used within the inner loops of parsing
and serialization, performance-critical applications. Have you checked to
see how this change affects the benchmarks?
While you technically can subclass the C++ Coded*Stream, it won't do any
good because none of the methods are virtual. In Python, while you can
technically override anything via monkey-patching, the encoding/decoding
code is all marked private and it's generally accepted that you shouldn't
fiddle with private internals of other packages. So, it is not really
possible to override things in this way in either of these languages.
It would be better if you wrote a protoc plugin which generates custom
parsing/serialization code that calls your own APIs. Or, if performance is
not critical, just write some code that iterates through all the fields
using getField()/setField() (on the Message and Message.Builder interfaces).
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
