-
Notifications
You must be signed in to change notification settings - Fork 18k
reflect, unsafe: should provide access to non-exported methods #47356
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
Comments
What kind of access do you suggest? Note that even before 1.11 the reflect package did not permit calling unexported methods. |
The reflect package allows one to examine the types in a program. It is not intended to be a way to defeat the type system. It does not step outside the bounds of Go's types and values, it just allows one to write programs that work on types not known at compile time. If the author of the package didn't want that method available, it does not matter what the mechanism is: it will not be available. |
Maybe you don't think Java, which can provide private method calls, is very good? |
Yes, I can only speak for myself but in my opinion Java is not very good if it allows to bypass the type system like this. Edit: When learning Go it is better not to compare too much with other programming languages because Go does many things differently, for very good reasons. |
Using unsafe and linkname, it's possible to call a non-exported method for now. |
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
Hello everyone, after version 1.11, access to non-exported methods was cancelled, but from a flexibility point of view, access to non-exported methods should be provided.Other languages do the same, otherwise it feels limited to use.
Thanks.
The text was updated successfully, but these errors were encountered: