Hmm, that's a good idea. They'd still have to be compiled into protoc, but at least they wouldn't have to be compiled into client code. The only problem is that it adds complication, I suppose. My second point is still an issue.
On Tue, Dec 2, 2008 at 8:23 AM, Chris <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
