You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just wondering why the pack and unpack on the any protos was removed. #329 This change makes it very difficult to work with the any protos. There’s no longer any access to the fully qualified name from the generated code. You can’t access the package or the nesting to construct the type url.
Using the module name is insufficient since you can’t tell from the module name what is part of the package (lower case) and which are nested messages (CamelCase).
This change seems very strange. Every language I’ve ever used that supports any has a pack and unpack function or at the very least supports the package a message belongs to or the fully qualified name. Any insight on why this was removed without providing a way to access the information to work with these from the generated code?
The decision to remove the fully qualified name and pack and unpack makes working with any protos (specifically on the packing side) essentially impossible without writing a bunch of code specific to the modules that you are using. All that to replicate information that comes from the generation process :'(
The text was updated successfully, but these errors were encountered:
Referring to: #329
Just wondering why the pack and unpack on the any protos was removed. #329 This change makes it very difficult to work with the any protos. There’s no longer any access to the fully qualified name from the generated code. You can’t access the package or the nesting to construct the type url.
Using the module name is insufficient since you can’t tell from the module name what is part of the package (lower case) and which are nested messages (CamelCase).
This change seems very strange. Every language I’ve ever used that supports any has a pack and unpack function or at the very least supports the package a message belongs to or the fully qualified name. Any insight on why this was removed without providing a way to access the information to work with these from the generated code?
The decision to remove the fully qualified name and pack and unpack makes working with any protos (specifically on the packing side) essentially impossible without writing a bunch of code specific to the modules that you are using. All that to replicate information that comes from the generation process :'(
The text was updated successfully, but these errors were encountered: