Yeah, I agree with it being cluttered if they were handled as options. I'm still trying to wrap my mind around the plug-ins and whether or not they are useful to my project.
If the development team would actually consider something to propagate generated code documentation, one thing to consider for non-java lanauges is doxygen. Doxygen comments look a lot like javadoc comments, and there is support for C, C++, Objective-C, Python, Fortran, C#, and a bunch of others. I wouldn't use Doxygen for Java, of course. (What would be the point?) C# is a little tricky, in that Microsoft defines an "XML Documentation" language but only gives you Sandcastle (unsupported, complicated) to do anything useful with them. On Dec 22, 1:28 pm, Kenton Varda <ken...@google.com> wrote: > The plugin framework is not meant for this. Plugins can only insert code at > points that have explicitly been declared by the original generator. For > example, in Java, the code generator generates one insertion point in each > class. So, you can add new methods to a message type, but you cannot stick > javadoc comments on the existing methods. > > I think that a system which let you arbitrarily edit the generated code > would be too fragile -- any change to the code generator would potentially > break plugins. In fact, I'm even worried that the current system is risky > because it allows plugins to get access to private members which could > change, but I don't see any way around that. > > All this said, I think it would be great if the protocol compiler supported > some format for documentation comments and automatically copied those > comments into the generated code. But no one has actually worked on this > yet. > > On Tue, Dec 22, 2009 at 6:42 AM, Christopher Piggott > <cpigg...@gmail.com>wrote: > > > Hmm maybe I can use the "UninterpretedOption" message to do this. > > Would something like this work? > > > message ChrisMessage { > > option javadoc = "This is an object representing Chris's Message"; > > repeated int32 field1 = 1 [javadoc="This is a javadoc for field 1]; > > repeated int32 field2 = 2 [javadoc="This is a javadoc for field 2]; > > } > > > Then write a plug-in that finds those and writes the ones whose > > NamePart.equals("javadoc") in as a /** comment */ > > > Possible? > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Protocol Buffers" group. > > To post to this group, send email to proto...@googlegroups.com. > > To unsubscribe from this group, send email to > > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@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.