On Nov 8, 2:06 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> 1. XML vs. Yet-Another-Proprietary-File-Format
> > The arguments against using XML at the wire-level are well documented,
> > but why, oh why, couldn't you have made the message definition format
> > (.proto) XML-based?
>
> Because XML is too verbose and, frankly, really hard to read.
> <message name="Foo">
> <field name="foo" number="1" type="int32" label="optional"/>
> <field name="bar" number="2" type="string" label="repeated"/>
> </message>
> vs.
> message Foo {
> optional int32 foo = 1;
> optional string bar = 2;
> }
I agree - both PB & XML are machine parsable, but PB is much more
human parsable. Maybe some people really like reading XML, but I'm not
a member of that club :-) XML is a tool that is invaluable in some
situations, but it is inappropriate to try and apply it to everything.
As another poster has suggested, you can convert proto files into XML
& then do what you like with them.
> > This is my single biggest complaint, and the one reason protobuf is
> > unsuitable for my project: the message definitions need to include
> > enough information to dynamically generate the user interface for both
> > displaying and composing messages.
>
> You can do this with custom options. For example, to annotate fields with
> descriptions for use in a UI:
>
> import "google/protobuf/descriptor.proto";
> extend google.protobuf.FieldOptions {
> optional string description = 12345;
> }
>
> message Foo {
> optional int32 foo = 1 [(description) = "The foo field."];
> repeated string bar = 2 [(description) = "The bar field."];
> }
>
> This is a new feature and I admit it is not adequately documented at the
> moment.
This is a _really_ nice feature, very handy. I can see you put this
comment in the SVN logs, but it would be worth updating the main docs
soon so more people can find out about it.
> > 2. Message Inheritance (vs. Extensions?)
> > Perhaps I just don't grok Extensions, but they seem more like a safety
> > feature than a re-usability mechanism.
>
> Our feeling about case 1 is that the best way to accomplish it is to simply
> embed an instance of the "base" message into your "derived" message. Sure,
> we could add a whole lot of code generation which makes this look like
> inheritance, but it does not seem worth the effort.
I'm fine with this - even though it's not "real" inheritance, it
fulfils the data structuring needs I have. I would have some
misgivings about being able to make a more complex inheritance scheme
as portable to as many languages as PB is. It is so easy to have
converters into JSON and simple data systems like that & it would be a
shame to make that harder or impossible. PB keeps things simple but
scalable...
> The most obvious problem with using inheritance in this case is that we
> would need multiple inheritance even just to cover existing use cases. Many
> people object to multiple inheritance for many reasons.
This is a powerful argument to not go there. I use C++ all the time &
like the power and flexibility of the language, but oh my does it come
at a cost of complexity to handle things like this. If you only ever
intended to have PB connections between C++, Java, and other languages
of similar power, then it might make sense to consider inheritance,
but not with the wide range of language support that currently exists.
> > 3. Typedefs
> > E.g., "UUID=string", "Timestamp=double", etc. Syntactic sugar is
> > always good.
>
> Even many fully-featured programming languages -- e.g. Java -- don't provide
> this.
True, but it doesn't mean it's a bad idea. I would suggest using the C
preprocessor to add #define for the typedefs you want. This way, it
doesn't interfere with PB, but allows you to add typedefs to your
data. I wouldn't mind seeing something like this in PB natively, but
it's not a major thing.
I suppose you could use that "extend FieldOptions" feature you
described to add meta-data describing the type, but it seems a bit of
overkill.
> 4. Built-un UUID Type
>
> > There are lots of other built-in types I'd like to have, but I think
> > this one's a must for a message encoder.
>
> What's wrong with defining your own UUID message? What would we gain from
> having it built-in?
Agreed - this type is way too specialized to build into the language.
It may be common in some classes of application development, but
there's plenty of people like me who never use them. If PB added UUID,
then there would be calls for all kinds of application specific types
to be built in, such as date/time. In particular, since UUID is a
string, there seems little sense adding type handling for a formatted
string.
Jeff
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
