google-code-export / protostuff

Automatically exported from code.google.com/p/protostuff
Apache License 2.0
1 stars 1 forks source link

Compiler option to use primitive numbers if the field is optional #51

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I am sure there is a valid reason but I dont know it.  In the java bean code 
generation you use this to map primitives to integers:
map_primitive_wrapper ::= [
    "int": "Integer",
    "long": "Long",
    "float": "Float",
    "double": "Double",
    "boolean": "Boolean",
    default: key
]

Why do you do this?  I manually changed all wrappers into primitive types and 
it worked as normal..  What benefit  does converting to the Wrapper give you.  
I dont want the extra cost of autoboxing to the Wrappers and back etc, and I 
was hoping to generate classes that implement an existing interface.  And the 
interface has methods that return primitive long for some of the methods..

I can easily change the generation template I guess, but wondered why this isnt 
done out of the box.

thanks for your help!

Ant

Original issue reported on code.google.com by anthony....@yahoo.co.uk on 7 Feb 2011 at 11:15

GoogleCodeExporter commented 9 years ago
You remember the boolean hasXX protobuf has, using a wrapper, we can avoid 
those extra boolean variables.

This also has the advantage when the message is used on a templating engine 
(jsp, velocity, etc) ... there is no extra auto-boxing when reflection is used. 

I have been planning to do add code generation without auto-boxing (including 
primitive lists) ... 
I'll try to add it on the upcoming release.

Original comment by david.yu...@gmail.com on 7 Feb 2011 at 11:35

GoogleCodeExporter commented 9 years ago
Btw those extra protobuf boolean hasXX vars are for the validation checks 
(required fields, default value handling)

Original comment by david.yu...@gmail.com on 7 Feb 2011 at 11:43

GoogleCodeExporter commented 9 years ago
I've just added a compiler option: primitive_numbers_if_optional
booleans will still be wrapped (There is no object creation overhead ... its 
either Boolean.TRUE or Boolean.FALSE)
@rev 1253.

Original comment by david.yu...@gmail.com on 13 Feb 2011 at 4:32

GoogleCodeExporter commented 9 years ago

Original comment by david.yu...@gmail.com on 14 Feb 2011 at 12:51

GoogleCodeExporter commented 9 years ago
this is great, thanks!  How do I tell what build this went into?

Original comment by anthony....@yahoo.co.uk on 16 Feb 2011 at 12:52

GoogleCodeExporter commented 9 years ago
1.0.0

Original comment by david.yu...@gmail.com on 16 Feb 2011 at 1:33

GoogleCodeExporter commented 9 years ago
oh ok, so 1.0.0 is a later version than 1.0.0.M7 ?

Original comment by anthony....@yahoo.co.uk on 16 Feb 2011 at 1:37

GoogleCodeExporter commented 9 years ago
Yes.  Btw, you can now use -Dproto_path=$path similar to protoc's --proto_path 
arg.

Original comment by david.yu...@gmail.com on 16 Feb 2011 at 1:43

GoogleCodeExporter commented 9 years ago
I just noticed that this only works if the fields are optional...  Whats the 
reason for that please?  

Original comment by anthony....@yahoo.co.uk on 16 Feb 2011 at 2:39

GoogleCodeExporter commented 9 years ago
See the generated schema's method "isInitialized".  That's where the wrapper is 
needed for required fields.

Original comment by david.yu...@gmail.com on 16 Feb 2011 at 9:38