-
Notifications
You must be signed in to change notification settings - Fork 43
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
ng: handling of unexported Go types #170
Comments
A simple example I encountered just now, as I tried to set an unexported variable in Sebastien's go-hep, based on ng:
|
The example in @sbinet original comment really should (and I think can be made to) work. But @glycerine points out a trickier fundamental limit of the reflect-based approach. I think for now I'm going to modify the type checker to reject unexported struct fields in type definitions, so at least the errors are clear. |
I think you can set unexported fields. https://stackoverflow.com/questions/42664837/access-unexported-fields-in-golang-reflect |
I suppose we already use plenty of |
Encouragement: It would seem odd not to be able to set one's own fields, from within one's own package. I verified that the stackoverflow technique works. When I replaced
with something approximately like
and then writing to unexported fields went through. |
This requires the implementation of reflect.StructOf be relaxed to allow creating structs with unexported fields. That is https://golang.org/cl/85661 For #170
This works. Thanks @glycerine. Unfortunately your particular example needs an improvement to More generally, we need to come up with rules for setting unexported fields. It is entirely reasonable when sitting in the ng> interpreter to change any field you want. (In fact, there are lots of other "superuser"-style powers I would like to add to the active interpreter.) But in general, an ng program should follow the exported/unexported rules of Go. So loaded packages shouldn't be able to do this. What about writing to unexported fields from inside blocks? |
Cool. I'm not familiar with |
consider the following Go
pkg1
:this will work:
where
simple-ok.ng
is:but this will fail with
simple-err.ng
:this boils down to: how to handle (and represent) values of unexported types?
The text was updated successfully, but these errors were encountered: