Kenton Varda wrote:
> Here's the major changes (from CHANGES.txt):
>
> General
> * Repeated fields of primitive types (types other that string,
> group, and
> nested messages) may now use the option [packed = true] to get a more
> efficient encoding. In the new encoding, the entire list is written
> as a single byte blob using the "length-delimited" wire type. Within
> this blob, the individual values are encoded the same way they would
> be normally except without a tag before each value (thus, they are
> tightly "packed").
I see http://code.google.com/apis/protocolbuffers/docs/proto.html has
been updated.
I will add Haskell support for this.
> * For each field, the generated code contains an integer constant
> assigned
> to the field number. For example, the .proto file:
> message Foo { optional int bar_baz = 123; }
> would generate the following constants, all with the integer value
> 123:
> C++: Foo::kBarBazFieldNumber
> Java: Foo.BAR_BAZ_FIELD_NUMBER
> Python: Foo.BAR_BAZ_FIELD_NUMBER
> Constants are also generated for extensions, with the same naming
> scheme.
> These constants may be used as switch cases.
Currently the wire layer has the field number baked in; it is never
exposed except through the reflection API.
Not hard to define a bunch of Int values. But in Haskell these cannot
be used as case targets. To do that I have to create the Int values as
Enum constructors. Which is less good.
For now I'll just ignore them, and add a note about it to the user.
This will be a demand driven feature.
> other version of Google Test if needed.
> * It is now an error to define a default value for a repeated field.
> Previously, this was silently ignored (it had no effect on the
> generated
> code).
easy
> * Fields can now be marked deprecated like:
> optional int32 foo = 1 [deprecated = true];
> Currently this does not have any actual effect, but in the future
> the code
> generators may generate deprecation annotations in each language.
easy
> protoc
> * The type name resolver will no longer resolve type names to
> fields. For
> example, this now works:
> message Foo {}
> message Bar {
> optional int32 Foo = 1;
> optional Foo baz = 2;
> }
> Previously, the type of "baz" would resolve to "Bar.Foo", and
> you'd get
> an error because Bar.Foo is a field, not a type. Now the type of
> "baz"
> resolves to the message type Foo. This change is unlikely to make a
> difference to anyone who follows the Protocol Buffers style guide.
Ack, the Haskell version needs to be updated to track this change.
This means I have to go back and understand the name resolution module
in my Haskell implementation.
Hmmm....
It currently has a "resolve in environment" that returns the first hit.
I'll have to update that.
> C++
> * DescriptorPool::AllowUnknownDependencies() may be used to tell
> DescriptorPool to create placeholder descriptors for unknown entities
> referenced in a FileDescriptorProto. This can allow you to parse
> a .proto
> file without having access to other .proto files that it imports, for
> example.
hmmm....odd.
> Java
> * New I/O methods parseDelimitedFrom(), mergeDelimitedFrom(), and
> writeDelimitedTo() read and write "delemited" messages from/to a
> stream,
> meaning that the message size precedes the data. This way, you
> can write
> multiple messages to a stream without having to worry about delimiting
> them yourself.
This will help responding to that FAQ.
--~--~---------~--~----~------------~-------~--~----~
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
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---
