Re: proto file naming and outer class collisions

2008-11-13 Thread Kenton Varda 
BTW, you didn't have to rename your .proto file.  You could have just used
the java_outer_classname to make it produce a different class name.

On Thu, Nov 13, 2008 at 11:40 AM, Kenton Varda [EMAIL PROTECTED] wrote:

 You're using the java_multiple_files option, I take it?
 The outer class is still necessary to store the file's descriptor and any
 top-level extension definitions.  I suppose the descriptor could be moved
 into the first class defined in the file but it will take some work and
 seems like a low priority.  I don't think it ever makes sense to put the
 extensions inside some other class but not all protos have top-level
 extensions.


 On Thu, Nov 13, 2008 at 10:04 AM, bmadigan [EMAIL PROTECTED] wrote:


 I think I'm missing somthing in the style guidelines. If I have a
 proto file called trip_summary.proto, which contains a message
 TripSummary, protoc throws the following error:

 -protoc-single:
 [exec] --java_out: trip_summary.proto: Cannot generate Java
 output because the file's outer class name, TripSummary, matches the
 name of one of the types declared inside it.  Please either rename the
 type or use the java_outer_classname option to specify a different
 outer class name for the .proto file

 So, renaming the file to 'trip_summary_protos.proto', protoc generates
 2 Java files, one called TripSummaryProtos.java, containing a static
 TripSummaryProtos, which contains an inner TripSummary class.
 Setting the option 'java_multiple_files=true', I get 2 java files,
 with the TripSummary class referencing all of the static members of
 TripSummaryProtos. This doesn't cause any problems with using
 TripSummary class (that I know of), but why is the container class
 necessary?
 Should I just define all of my messages in one file and ignore the
 outer class in my code?
 -bmadigan
 



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: null values should be treated as no value

2008-11-13 Thread Kenton Varda 
I agree, the setters should either throw NPE or should treat setFoo(null)
the same as clearField().

On Thu, Nov 13, 2008 at 7:39 AM, bivas [EMAIL PROTECTED] wrote:


 Hi,
 I'm using the Java output feature of protobuf for my app.
 I found that protobuf doesn't handle null values as well as i would
 expect it.

 for example:

 message MyMessage {
   required int32 id = 1;
   optional string code = 2;
 }

 in java:

 MyMessage message = MyMessage.newBuilder().setId(3).setCode(null).build
 ();
 message.writeTo(System.out); // --- this will result a
 NullPointerException when trying to write the code field

 the reason is that in the created java source the setCode() method
 looks like this:

 public Builder setCode(java.lang.String value) {
result.hasCode = true; // the field flag indicate a value
 while there isn't!
result.code_ = value;
return this;
 }

 method should look like:

 // for optional fields
 public Builder setCode(java.lang.String value) {
result.hasCode = (value != null) ;
result.code_ = value;
return this;
 }

 // for required fields
 public Builder setCode(java.lang.String value) {
assert value != null;
result.hasCode = true;
result.code_ = value;
return this;
 }


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---