Kenton Varda wrote:
> On Mon, Dec 1, 2008 at 6:46 PM, aantono <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> message Person
> java_implement_interface = com.domain.Name <http://com.domain.Name>;
> required string name;
> required int32 age;
> }
>
>
> More precisely:
>
> message Person {
> option java_implement_interface = "com.domain.Name
> <http://com.domain.Name>";
> required string name = 1;
> required int32 age = 2;
> }
Why not use the new mechanism, putting the java extensions into
"java_ext.proto":
import "java_ext";
message Person {
option (java_ext.implement_interface) = "com.domain.Name
<http://com.domain.Name>";
required string name = 1;
required int32 age = 2;
}
>
> And the effect of this is simply that when protoc generates the Person
> class, it declares it as implementing com.domain.Name
> <http://com.domain.Name>.
>
> This is a very simple change, so I may be convinced to accept it. My
> main concerns are:
>
> * Adding another option imposes non-zero overhead even on people who
> don't use the option, since it increases the code generated for
> descriptor.proto. The size of descriptor.proto's generated code is
> already somewhat of a problem.
The java_ext.proto code would not be part of descriptor.proto code.
Non-java targets could eliminate it.
> * I'm somewhat uneasy with the idea of generated protobuf code
> depending on non-generated code (other than standard libraries and
> libprotobuf). This goes against the model. It would not work in our
> internal build system, which assumes that protobuf code never has such
> dependencies. I am worried that making the model more complicated in
> this way will lead to other problems down the road; e.g. if protocol
> buffers are integrated better into other build systems, they may also
> dislike this.
>
> I can see where this feature would be useful but I'm not sure if it
> outweighs these issues.
>
> What do other people think?
I think that having target specific "java_ext.proto",
"python_ext.proto", and "cpp_ext.proto" that define hints to protoc's
code generation would be a good idea. The existing java* options and
the "ctype=CORD" options are legacy examples that would be in
"java_ext.proto" and "cpp_ext.proto" if redesigned today. This way
"descriptor.proto" is stable against adding target specific extensions.
The code bloat only occurs on the target platform, though there is data
bloat in the reflection storage on all platforms.
Is there any technical reason it could not go into a separate
"java_ext.proto" file?
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---
