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.
