The "packed" encoding would not provide much benefit for strings, groups, or
messages, so we did not implement it for those.  You can still have regular
"repeated" fields of these types, just not packed ones.  There's no
theoretical reason why we couldn't implement packed repeated strings,
groups, and messages, but there is one practical consideration:  strings and
messages already use the length-delimited wire type, whereas packed repeated
fields also use this type.  This could make problems harder to debug if
someone were to erroneously add the "packed" annotation to an existing
repeated field and then try to parse old messages with it.  There was also
some thought that it would be nice if parsers could accept repeated fields
as packed or unpacked regardless of the .proto definition, and only the
serialization side would pay attention to the option, since this would allow
you to switch to packed fields without breaking compatibility.  However, we
haven't implemented any such feature yet since it would increase code bloat.
BTW, the encoding docs will be updated along with the release sometime next
week, so you might want to wait rather than try to reverse-engineer the
code.

On Fri, May 8, 2009 at 3:18 PM, Chris Kuklewicz <turingt...@gmail.com>wrote:

>
> Now to consider updating the Hakell implementation.
>
> I have pulled out the new descriptor.proto and generated new code from
> it, this compiles fine.  I now have "packed" and "deprecated".
>
> I just started reading the code for the release candidate, so as to
> understand "packed".
>
> Only "repeated" fields may have "[packed = true]"
>
> >      case FieldDescriptor::TYPE_STRING:
> >      case FieldDescriptor::TYPE_GROUP:
> >      case FieldDescriptor::TYPE_MESSAGE:
> >      case FieldDescriptor::TYPE_BYTES:
> >        // Can't have packed fields of these types: these should be caught
> by
> >        // the protocol compiler.
>
> My compiler will need the same checks.
> Those types do not need any changes in the runtime library.
> Not having repeated message types seems like a poor situation.
>
> Kenton: why are these disallowed?
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to