proposal: reflect: list unexported methods #29126
Labels
Milestone
Comments
ianlancetaylor
changed the title
|
Can you explain the problem better please? I don't understand the issue. Letting users see the unexported methods through reflect opens a number of holes in type isolation. I think it very unwise. The system is designed the way it is for good reason. |
at beginning i thought those instances of reflect unexported method could simply panic. That did not seem much harm. Second thoughs, i can foresee a far fetched scenario where using reflect unexported methods type signature it is possible to call them despite their reduced visibility. Thanks for considering. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I would like that the reflect package list all methods of a type, including unexported methods.
Without those data it is not possible to fully serialize a type at runtime.
This capability is missing to build plugin at runtime without access to the original source files.
Because the reflect package does not list those methods, a plugin that would like to re create those types can not be loaded, a runtime error is returned because the same named type have different definitions.
I think this is a change that can happen without breaking the compatibility guarantee.
In order to keep the compatibility guarantee i think the current api could be changed to add new methods to separately list unexported methods.
NumUnexported() int/UnexportedMethod(int) reflect.MethodMethodByName(string) reflect.Methodmight be changed to return unexported results without harming current implementations.Can those additions, or something similar, be considered for future versions of the standard library ?
The text was updated successfully, but these errors were encountered: