This matches an API already present in proto2 (const DescriptorPool* FileDescriptor::pool()). However there is a slightly subtle implication here. In proto2, the relationship between Descriptor and MessageFactory is 1:many. You can create as many DynamicMessageFactory instances as you want, and each one will have its own independent DynamicMessage prototype and computed layout for the same underlying Descriptor. In practice the layouts will all be the same, but one thing that could be distinct is that each can have its own extension pool, which is a DescriptorPool that will be searched for extensions when parsing. In contrast, upb does not have a separate "message factory" abstraction. That means that each upb_msgdef has a single distinct layout, in other words a 1:1 correspondence between descriptor and layout. This means that there is no way to create multiple message types for the same descriptor that have distinct extension pools. If you want a different set of extensions, you must create a separate upb_symtab with a distinct set of descriptors. This change further entrenches that upb_filedef:upb_symtab is a 1:1 relationship. A single upb_filedef cannot be a member of multiple symbol tables. In practice this was already true (there is no way to add a single filedef to multiple symbol tables) but this change codifies this 1:1 relationship.pull/13171/head
parent
a81b47025a
commit
ee49a8d7df
4 changed files with 34 additions and 1 deletions
Loading…
Reference in new issue