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 <[email protected]> wrote: > On Sat, Apr 2, 2011 at 3:53 PM, Jeffrey Damick <[email protected]>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 <[email protected]> wrote: >> > On Tue, Feb 8, 2011 at 5:47 AM, Evan Jones <[email protected]> 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 [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. >> >> > -- 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.
