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
On Sat, Apr 2, 2011 at 3:53 PM, Jeffrey Damick 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 jso
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 seein
I'm starting to look at the patch (meant to start end of last week but got
caught up in other stuff)
On Tue, Feb 1, 2011 at 9:30 PM, Kenton Varda wrote:
> On Tue, Feb 1, 2011 at 3:17 PM, Jason Hsueh wrote:
>
>> Conceptually this sounds great, the big question to me is whether this
>> should be
Unfortunately, the Google C++ Style Guide prescribes inconsistency. Only
simple inline methods can use lowercase-with-underscores naming; everything
else is supposed to use capitalized camelcase.
On Sat, Feb 5, 2011 at 8:40 AM, Frank Chu wrote:
> Can the naming be
>
> visit_bar()
> visit_baz()
Can the naming be
visit_bar()
visit_baz()
then? It's good to have some consistency.
Frank
On Sat, Feb 5, 2011 at 08:06, Kenton Varda wrote:
> On Wed, Feb 2, 2011 at 10:13 AM, Henner Zeller <
> henner.zel...@googlemail.com> wrote:
>
>> I guess the naming is confusing in the example. The Visit
On Wed, Feb 2, 2011 at 10:13 AM, Henner Zeller wrote:
> I guess the naming is confusing in the example. The Visit is per
> field-name; but since the typed is named the same as the field in this
> example, it is confusing.
>
Yes, sorry. Better example:
message MyStream {
option generate_v
Just want to add my vote for this feature to be added to the base
compiler. I've implemented similar multiplexing patterns over and over
again, and would love for the compiler to free me from writing and
maintaining that code.
On 2 Feb., 19:13, Henner Zeller wrote:
> On Tue, Feb 1, 2011 at 23:02,
On Tue, Feb 1, 2011 at 23:02, fpmc wrote:
> Your proposal has one VisitXXX function for each repeated type. How
> does it handle a message with two repeated fields of the same type?
I guess the naming is confusing in the example. The Visit is per
field-name; but since the typed is named the same
Your proposal has one VisitXXX function for each repeated type. How
does it handle a message with two repeated fields of the same type?
On Feb 2, 2:30 pm, Kenton Varda wrote:
> On Tue, Feb 1, 2011 at 3:17 PM, Jason Hsueh wrote:
> > Conceptually this sounds great, the big question to me is wheth
On Tue, Feb 1, 2011 at 3:17 PM, Jason Hsueh wrote:
> Conceptually this sounds great, the big question to me is whether this
> should be implemented as an option in the compiler or as a separate plugin.
> I haven't taken a thorough look at the patch, but I'd guess it adds a decent
> amount to the
Conceptually this sounds great, the big question to me is whether this
should be implemented as an option in the compiler or as a separate plugin.
I haven't taken a thorough look at the patch, but I'd guess it adds a decent
amount to the core code generator. I have a preference for the plugin
appro
12 matches
Mail list logo
