On Mon, Dec 1, 2008 at 6:46 PM, aantono <[EMAIL PROTECTED]> wrote:
> message Person
> java_implement_interface = com.domain.Name;
> required string name;
> required int32 age;
> }
>
More precisely:
message Person {
option java_implement_interface = "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.
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.
* 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?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
