It just seems like a lot machinery has to be repeated across
encoders/decoders to walk the messages & fields vs. a more event driven
style like your vistor writer/filler which would abstract some of that, but
it comes down to a matter of taste i suppose. I'm definitely in favor the
generic vistor adapter..
On Sun, Apr 3, 2011 at 3:28 AM, Kenton Varda <ken...@google.com> wrote:
> On Sat, Apr 2, 2011 at 3:53 PM, Jeffrey Damick <jeffreydam...@gmail.com>wrote:
>> This may be a naive question, but wouldn't the format in text_format
>> be a prime example another "protocol"? It seems that if you are able
>> to reuse the vistor generate the text format, then it would be easily
>> extendable by others for json or the latest encoding of the week.. I
>> look forward to seeing it pushed into the tree.
> TextFormat is already implemented purely in terms of public interfaces --
> namely, the reflection interface. Thus it is already possible to write,
> say, a JSON encoder/decoder for protobufs, and indeed several people have
> done this.
> The current visitor proposal (which I haven't had time to work on in
> awhile, but will get back to eventually...) does not provide any new way to
> implement TextFormat, because all visitor classes are type-specific. In
> other words, to implement TextFormat via visitors you would need to write an
> implementation for every single type, rather than one implementation that
> covers all types. This could perhaps be solved by inventing some sort of
> generic visitor adapter, but I haven't done any such thing in my patch,
> since reflection already solves most of the same problems.
>> On Feb 8, 2:34 pm, Kenton Varda <ken...@google.com> wrote:
>> > On Tue, Feb 8, 2011 at 5:47 AM, Evan Jones <ev...@mit.edu> wrote:
>> > > The Visitor class has two standard implementations: "Writer" and
>> > >> "Filler". MyStream::Writer writes the visited fields to a
>> > >> CodedOutputStream, using the same wire format as would be used to
>> > >> MyStream as one big message.
>> > > Imagine I wanted a different protocol. Eg. I want something that
>> > > each message, or maybe compresses them, etc. Will I need to subclass
>> > > MessageType::Visitor for each stream that I want to encode? Or will I
>> > > to change the code generator?
>> > To do these things generically, we'd need to introduce some sort of
>> > equivalent of Reflection for streams. This certainly seems like it
>> could be
>> > a useful addition to the family, but I wanted to get the basic
>> > out there first and then see if this is needed.
>> > Note that I expect people will generally only "stream" their top-level
>> > message. Although the proposal allows for streaming sub-messages as
>> well, I
>> > expect that people will normally want to parse them into message objects
>> > which are handled whole. So, you only have to manually implement the
>> > top-level stream, and then you can invoke some reflective algorithm from
>> > there.
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To post to this group, send email to email@example.com.
>> To unsubscribe from this group, send email to
>> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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