[protobuf] submessages that don't specify a package?

[Matthieu Morel]

Hi,

I have some protobuf schemas I want to import, but they are defined in the 
default package (i.e. without a package), and I am not able to use them for 
submessages.

e.g. schema1.proto:
message A {
  optional string x = 1;
}

I am not able to use A as a submessage in schema2.proto:

import schema1.proto
message B {
  optional A a = 1;
}

The generated code (java output) does not compile due to this statement in 
Schema2.java:

com.google.protobuf.Descriptors.FileDescriptor
  .internalBuildGeneratedFileFrom(descriptorData,
new com.google.protobuf.Descriptors.FileDescriptor[] {
  .Schema1.getDescriptor(),
}, assigner);


- there is a dangling dot in the 4th line.


I'd expect to have just Schema1 in this case, instead of .Schema1 with does 
not compile.


Is this expected behaviour? I can reproduce it with protobuf 2.6 and 3.0

Note that if I specify a package in schema1.proto things work fine.


Thanks!

Matthieu



-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Compile-time lambda functions in .proto files

[Joe Eagar]

Hi.  I independently came up with a ProtoBuf-like system, with an 
interesting twist I thought I'd share: compile-time lambda functions for 
controlling how objects are serialized.  Instead of auto-generating class 
definition code, my system works with existing classes.  Rather than 
writing interface code between generated classes and an existing set of 
code, you write lambda functions inside the equivalent of .proto files 
(.struct files) that describe how the system processes classes that already 
exist.

Here's an example of a .struct file:

Object {
  property : int | obj.property.id;
}

The lambda function comes after the pipe character; it gets a single 
argument, 'obj', which is an instance of Object.  At serialization time, it 
transforms 'property' from an object reference into an integer.  The 
general idea is to embedd this with the code.  For example:

class Object {
//has an integer
}
ObjectDefinition = [
Object {,
  property : int | obj.property.id;',
}
];

In the original design, there were lambda functions for controlling how 
deserialization would happen, too, so you might see:
property : int | obj.property.id | get_object_from_id(obj.id);

But these turned out to not be necessary for my use case (I was writing 
code in JavaScript, which simplified deserialization given JS's 
dynamic--more like, total lack of a--type system).

Anyway, you can find more information here:
https://github.com/joeedh/STRUCT/wiki/Intro-and-Examples

P.S.: this is not an advertisement.  In many respects ProtoBuf is superior 
to what I've come up with, and frankly I don't have the time to maintain my 
own system.  I only created it because, at the time I wasn't able to find 
an existing solution.  If the ProtoBuf developers want to steal my ideas 
(please! I hate maintaining things!), they are free to do so.

-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.