I agree that there should be a way to specify options on the command-line. This applies to pretty much *all* options -- optimize_for, java_Package, ctype, etc. It would even be useful to be able to munge package and class names on the command-line, so that you can generate the same .proto file using two different sets of options and not have the classes conflict. I would like to create a general way to do this, but it's a slightly complicated problem. One should be able to express fairly arbitrary things like "For all string fields, set option foo.". I want to have an expressive syntax but don't want to go off the deep end in inventing a whole DSL for option munging.
For now I think I'm going to go ahead and change the default for this option in the next release. On Fri, Mar 6, 2009 at 12:30 AM, Jon Skeet <sk...@pobox.com> < sk...@pobox.com> wrote: > > On Mar 5, 11:39 pm, Kenton Varda <ken...@google.com> wrote: > > As you know if you've read the docs carefully, when using C++ or Java > > protocol buffers, for best performance you need to add a line to your > .proto > > files: > > > > option optimize_for = SPEED; > > <snip commentary> > > I think there are three issues here: > > 1) Yes, it's really easy to miss that. Shortly after PBs were released > I saw a blog post showing how "slow" PBs are - and then I pointed out > the optimize_for option... > 2) It's a pain to have to use a whole different .proto file just to > specify this option. While I believe many options *should* be in > the .proto file (particularly where they might affect individual > fields etc) I think this would make sense to have as a compiler/ > generator flag (it could be in either place, for situations where the > two are split). For instance, you may have a memory-limited client > where speed doesn't matter, and a memory-rich server processing > gazillions of these things - they should be able to use the > same .proto file. > 3) Backward compatibility. > > I suspect we could really do with the compiler working in four > different modes: > > 1) Default to SPEED when otherwise undefined; obey proto file > otherwise > 2) Default to CODE_SIZE when otherwise undefined; obey proto file > otherwise (current mode) > 3) Generate code using SPEED regardless of proto file > 4) Generate code using CODE_SIZE regardless of proto file > > I think it would we should at least be able to specify "I want the old > behaviour" on the command line just because that makes the backward > compatibility story easy: "use this argument and it's all as it was" - > but I'd be happy for the actual default to be changed. > > (Evil thought: make the default a build-time setting for the compiler > itself, so if you want to build protoc with the old behaviour you can. > Almost certainly not a good idea, but it's amusing to think of the > number of places this *could* be set...) > > Jon > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
