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
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.Method
MethodByName(string) reflect.Method might 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:
ianlancetaylor
changed the title
feature request: reflect: list unexported methods
proposal: reflect: list unexported methods
Dec 6, 2018
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.
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.
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.Method
MethodByName(string) reflect.Method
might 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: