Options

[Chris]

The fact that options are defined within the .proto file doesn't make
sense in some situations to me:
While I do see the point of putting an "java_outer_classname"
definition into a file, because there is a strong relation between the
message and what we call it.
However "optimize_for" for example seems misplaces in the code: isn't
that supposed to be a compile option? Consider the situation where you
want to compile the same .proto sources twice: once for a mobile
device using the "lite" version and the other time speed optimized,
but not "lite" as you want to use reflection.
Or it is possible to pass these options to the compiler directly?

[Kenton Varda]

We'd like to make it possible to override options from the command-line, but no one has gotten around to implementing it.  How best to do this is unclear, particularly when you consider message-level and field-level options as well.  What should the flag syntax be to, say, set "packed = true" on all repeated primitive fields?  Or just on the field "MyMessage.some_field"?  (The "packed" option may not be the best example, but let's imagine we had other field options that really do make sense to set on the command line.)

Ideally, I'd like any solution we come up with to solve the general problem, or at least have a clear way to expand it to cover all option types in the future even if we only support file-level options initially.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

[Dave Bailey]

I think it would be really helpful to be able to override anything in
FileOptions from the command line, at least. I'm not sure if anyone
would really want to override options at other levels (Message/Field/
Enum/Service/Method)... but maybe something like:

# apply a file-level option to specific files
protoc +file+foo.proto,bar.proto+optimize_for=SPEED foo.proto
bar.proto baz.proto

# apply a file-level option to all files
protoc +file+optimize_for=SPEED

# Apply a message-level option to specific messages
protoc +message+Foo,Bar+message_set_wire_format=1 foo.proto bar.proto
baz.proto

# Apply a message-level option to specific messages in specific files
protoc +message+foo.proto:Foo,bar.proto:Bar+message_set_wire_format=1
foo.proto bar.proto baz.proto

# Apply a message-level option to all messages in a set of files
protoc +message+foo.proto:,bar.proto:+message_set_wire_format=1
foo.proto bar.proto baz.proto

# Apply a message-level option to all messages in all files
protoc +message+message_set_wire_format=1 foo.proto bar.proto
baz.proto

# Apply a field-level option to specific fields in specific messages
in specific files (ugh)
protoc +field+foo.proto:Foo.bar+packed=1 foo.proto

# Apply a field-level option to all fields in all files (???)
protoc +field+packed=1 foo.proto

# Apply a field-level option to a particular field in all messages in
all files (NO!?)
protoc +field+:.baz+packed=1 foo.proto bar.proto

I don't know why someone would apply a field-level option to all
fields in all files, but... it would technically make it possible to
compile a set of .proto files with packed=true on all fields (assuming
protoc doesn't abort compilation if packed=true is applied to a non-
repeated or non-primitive field).

I don't have a strong opinion about delimiters in the option syntax; I
just chose some that should hopefully work without ambiguity.

-dave

On Jan 31, 6:58 pm, Kenton Varda <ken...@google.com> wrote:
> We'd like to make it possible to override options from the command-line, but
> no one has gotten around to implementing it.  How best to do this is
> unclear, particularly when you consider message-level and field-level
> options as well.  What should the flag syntax be to, say, set "packed =
> true" on all repeated primitive fields?  Or just on the field
> "MyMessage.some_field"?  (The "packed" option may not be the best example,
> but let's imagine we had other field options that really do make sense to
> set on the command line.)
>
> Ideally, I'd like any solution we come up with to solve the general problem,
> or at least have a clear way to expand it to cover all option types in the
> future even if we only support file-level options initially.
>

> On Sun, Jan 31, 2010 at 11:28 AM, Chris <hsifdr...@gmail.com> wrote:
> > The fact that options are defined within the .proto file doesn't make
> > sense in some situations to me:
> > While I do see the point of putting an "java_outer_classname"
> > definition into a file, because there is a strong relation between the
> > message and what we call it.
> > However "optimize_for" for example seems misplaces in the code: isn't
> > that supposed to be a compile option? Consider the situation where you
> > want to compile the same .proto sources twice: once for a mobile
> > device using the "lite" version and the other time speed optimized,
> > but not "lite" as you want to use reflection.
> > Or it is possible to pass these options to the compiler directly?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to prot...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > protobuf+u...@googlegroups.com<protobuf%2Bunsu...@googlegroups.com>

[Kenton Varda]

The problem I keep running into here is that anything one proposes leaves more to be desired.  If I can munge options, shouldn't I also be able to munge types?  What if I want to take a message type, remove some fields that I don't care about (so that I can drop some dependencies), change a particular repeated field to [packed=true], and change the type name so that it doesn't conflict with the original type?  All reasonable things to want to do...

I was thinking that the way this should really be accomplished is with scripts written in a real programming language which modify the FileDescriptorProto (the parsed representation of a .proto).  You could actually inject such a script today by writing it as a wrapper around a plugin -- if only the standard code generators were plugins.

I wonder if we should make this usage model easier somehow.  We could introduce filtering plugins that have a chance to modify the parsed files before the code generator plugins are executed.

Of course, writing a filter plugin may be overkill when all you want is to change a top-level file option.  So maybe we should provide a special case just for file options since they'd be by far the most widely-used case.

To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.