We introduce hpb::ExtensionRegistry::generated_registry. In the future, Parse calls will default to this being the default registry, while still being able to supply their own (if needed).
PiperOrigin-RevId: 697690765
We introduce AddExtension, which'll take an ExtensionId. From there, our helper extracts the mini_table_ext() ptr and handles the upb_ExtensionRegistry behind the scenes.
The ctor for an ExtensionRegistry has been updated to just take an arena.
Just need to supply an extension, and let us handle the rest!
PiperOrigin-RevId: 696136849
Not invoked just yet, as extant users may expect the old `GetOrPromote` pathway.
An incremental Δ for getting message extensions up to parity with proto2.
PiperOrigin-RevId: 695723050
EnableIfHpbClass was too restrictive in the past; it was
toggled only if <T> was extended. This has been rectified
to toggle if T extends T::Access, which reflects the
true intention.
PiperOrigin-RevId: 693368653
At the moment, hpb's public api solely returns Ptr<const Extension>. We'd like to support all non-msg types like int32, int64, bool etc.
These should not return a Ptr<...> but the underlying primitive itself.
We start by adding support for int32 and int64.
PiperOrigin-RevId: 691490444
Have ExtensionIdentifier have a upb_MiniTableExtension* instead of subclassing a class that is just a plain holder for a upb_MiniTableExtension* with a getter with the same name
We generally want to lean toward composition over inheritance. Without a compelling reason for inheritance, let's prefer composition for clarity, flexibility, and evolvability. Locking oneself into an inheritance hierarchy has marred many a codebase.
PiperOrigin-RevId: 689380813
Hong Shin
Protobuf Team Bot