ok, thanks for pointing me to the right directions and your RPC
system, that should be helpful.
On Feb 27, 12:45 am, Kenton Varda wrote:
> Plugins are now mentioned in the docs in several places:
>
> http://code.google.com/apis/protocolbuffers/docs/reference/other.htmlhttp://code.google.com/apis
Plugins are now mentioned in the docs in several places:
http://code.google.com/apis/protocolbuffers/docs/reference/other.html
http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#plugins(similarly
for java-generated and python-generated)
http://code.google.com/apis/protoc
i think it would also be very helpful to have some sort of "dummy-
example-plugin" documentation.
at the moment i am completely lost how to begin to write the plugin.
but i dont want to whine: protobufs other documentation is excellent,
so maybe i am just getting too comfortable ;)
On Jan 6, 7:0
Yes. Sorry, I haven't had a chance to write up formal documentation yet.
See these two files:
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/plugin.proto
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/plugin.h
On Wed, Jan 6
Is the plugin framework already part of 2.3.0? I can't find any
documentation for this new feature besides some early brainstorming
posts.
On Dec 22 2009, 7:28 pm, Kenton Varda wrote:
> The plugin framework is not meant for this. Plugins can only insert code at
> points that have explicitly been
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
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 sti
How about using /// for those special line comments?
This would prevent accidental field comments.
Joern.
On 22.12.2009, at 17:12, Henner Zeller wrote:
> Hi,
> On Tue, Dec 22, 2009 at 06:42, Christopher Piggott wrote:
>> Hmm maybe I can use the "UninterpretedOption" message to do this.
>> Would
Hi,
On Tue, Dec 22, 2009 at 06:42, Christopher Piggott 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
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="
10 matches
Mail list logo