Allow generating code for message extensions about protostuff-googlecode-exported

[GoogleCodeExporter]

Yep it is not supported.  
Not sure if I can implement this in the near future (other priorities)
Feel free to submit a patch if you come up with something.

Original comment by [email protected] on 9 Jul 2010 at 7:38

[GoogleCodeExporter]

Here's a patch (against r1001) for protostuff-parser that parses and adds 
extension meta-data to the data model.

Description of modifications
* Created new type: Extension to hold extended fields
* Created new interface HasFields to allow reusing the Message field parsing 
code. Message and Extension both implement HasFields.
* Modified Message to allow nested extension definitions
* Modified Message to define extension ranges
* Modified Message to add extended fields (may not be necessary)
* Modified Proto to add list of Extensions

I haven't tried using the meta-data yet, so it's probably not exposed in a 
friendly manner.

Comments welcomed!

Original comment by [email protected] on 14 Jul 2010 at 7:59

Attachments:

• issue-25.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Minor modification to patch file: added getter method on Extension class to 
obtain extended message instance.

Patch was created from svn root (/trunk) instead of /trunk/protostuff-parser.

Original comment by [email protected] on 15 Jul 2010 at 4:00

Attachments:

• issue-25.patch

[GoogleCodeExporter]

Cool.
Didn't think it the changes were that obtrusive :-)
I was thinking that the Extension could simply subclass Message and simply add 
an isExtension() method on the message.
Are nested messages, nested enums allowed in the extend block?
In java form, how is it represented since the extend block does not really have 
a namespace.  I don't know how the nested stuff will derive its full name.
Also, the java formatting is inconsistent.

Original comment by [email protected] on 16 Jul 2010 at 8:22

[GoogleCodeExporter]

Yeah, it can probably be less obtrusive. I'm not very familiar with the 
codebase. Some of my modifications aren't required also.

Extension is not a Message. It cannot have nested message declarations, it 
cannot have additional extension. I haven't looked at the "officical" protobuf 
parser, but it seems to expect field and field group declarations only. So in 
fact, Message could extend Extension (or some other more appropriate name). 
This is why I created a HasFields interface.

Extensions are represented as public static fields of type GeneratedExtension 
in the message type. For example:

message A {
  extensions 1 to max;
}

message B {
  extend A {
    optional string foo = 1;
  }
}

Will declare a field "foo" in the B class which will of GeneratedExtension<A, 
String> type.

If the extend block is not declared in a message, the extension fields are 
declared in the proto namespace.

As for java formatting, I did my best, but must have missed some places. Do you 
have a coding convention file I can import in Eclipse?

Original comment by [email protected] on 16 Jul 2010 at 1:09

[GoogleCodeExporter]

I've attached the eclipse formatter.
I think your patch is good ... re-using existing code. (you've found a bug btw, 
adding the findEnumGroupFrom method is good)
The changes are plenty ... hopefully it does not have any side effects.
thinking of a way to minimize the changes ... 

I assume you're using this to generate client-side GWT code.
Are you also using the service metadata to generated client-side gwt rpc code?

Original comment by [email protected] on 16 Jul 2010 at 5:02

Attachments:

• eclipse-java-format.xml

[GoogleCodeExporter]

Another version of the patch. I've run the Eclipse formatter on the sections I 
changed (running it on the whole class modifies all sorts of other places). 

If I can make some suggestions regarding code formatting:
* configure the code formatter in each project and commit this (creates a 
.settings directory)
* use "Save Action" to apply formatting when saving a file
* set "svn:eol-style" to "native"

The result:
* a developer using Eclipse does not have to install your code standards, 
they're automagically available (and imposed)
* end-of-lines in the source files will be consistent regardless of the OS the 
developer uses

Another note for making patches easier: use svn:ignore for build artifacts. 
It's a bit tricky to get the correct set of files to include in a patch.

Back to the issue. Yes, I'm using client-side GWT code generation, but only for 
messages, not services.

Original comment by [email protected] on 16 Jul 2010 at 6:04

Attachments:

• issue-25.patch

[GoogleCodeExporter]

Patch applied (with a few modifications on Message.java) @ rev 1002

Thanks Philippe!

Original comment by [email protected] on 21 Jul 2010 at 8:20

• Changed state: Fixed

[GoogleCodeExporter]

Cool! Thanks for applying this as-is. Wasn't sure it was the best approach, 
just one that worked!

BTW, I've successfully used the patch to generate the required code in my GWT 
overlays. I can also contribute these modifications if you wish.

Original comment by [email protected] on 21 Jul 2010 at 1:35

[GoogleCodeExporter]

IIRC, the enum mode of your gwt overlays were strings instead of int yes?
I don't know what the standard is but I'm leaning towards int for space 
efficiency.
Currently, fed-one(wave protocol)also uses protostuff for their gwt overlays, 
and I believe they aren't customizing the enum to serialize as string.

If its already using the int value, I'd be happy to add it in the list of 
compilers.

Original comment by [email protected] on 21 Jul 2010 at 2:24

[GoogleCodeExporter]

Yes, I'm using strings, but the template can be easily adapted to use ints 
instead.

I was thinking of a patch to gwt_overlay, not an additional compiler "format". 
It's pretty trivial to add support for extensions in gwt_overlay (either using 
strings or ints). I can extract that part of my custom template, make it use 
ints and apply that to gwt_overlay.

As for standards, I don't know either, but I know that JsonFormat from 
protobuf-java-format uses strings. If I had to guess, I would say that native 
protobuf uses ints.

Original comment by [email protected] on 21 Jul 2010 at 2:34

[GoogleCodeExporter]

I'd welcome the patch. You can attach it here.

Thanks

Original comment by [email protected] on 21 Jul 2010 at 2:57