-
Notifications
You must be signed in to change notification settings - Fork 445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose field names via a public API #1284
Comments
+1, it would be really useful with enums using string constants. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Being able to access this would've allowed me to easily log the name of the payload being processed, as I am using oneof to enumerate all possible IPC payloads. I think this is a more than acceptable use case.
IMO, this data has been sitting in the library for 5 years and counting. It clearly works well enough, even if it is "not quite correct" or a "special-case". If the alternative is reflection, which is not performant, why should this remain an internal API? More importantly, why is the library the only one with easy access to this information?
My workaround uses reflection, building atop of the workaround here:
Having this functionality provided by the library would be incredibly valuable, and would cut out all of this boilerplate code.
The text was updated successfully, but these errors were encountered: