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..

thanks,
-jeff



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.
>
>
>>
>> thanks
>> -jeff
>>
>> 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
>> encode
>> > >> MyStream as one big message.
>> >
>> > > Imagine I wanted a different protocol. Eg. I want something that
>> checksums
>> > > 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
>> need
>> > > 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
>> functionality
>> > 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 protobuf@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.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@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.

Reply via email to