I am new to type safe, and can't figure out how to do following
package main
func test(){
print("In Test")
}
func main(){
a := "test"
a()
}
You might get better answers if you state what you're trying to achieve, as reflection is usually not the best way. But reflect will help if the functions are methods on a type (net/rpc is an example of this).
package main
import (
"fmt"
"reflect"
)
type T struct {}
func (T) Add(x, y int) int {
return x + y
}
func main() {
t := reflect.ValueOf(T{})
m := t.MethodByName("Add")
args := []reflect.Value{reflect.ValueOf(1), reflect.ValueOf(2)}
fmt.Println(m.Call(args)[0].Int())
}
If you were wondering how tools like godoc work, they parse the source rather than use reflection.
Edit: Playground version
A function can not be resolved from a string. However, you can assign a function to a variable.
a := test
a()
You can also put functions (assuming they all have the same signature) into a map:
var func_map := map[string]func() {
"test": test,
}
a := func_map["test"]
a()
Response to first comment by OP (too long to make another comment):
A function is not a "literal". "Literal" has a separate meaning.
Second, Go's runtime reflection does not have a lookup table mapping strings to functions. Even if it did, functions are not linked into the binary unless linked to by other code. Code only called in this method would not be in the binary.
Third, making a mapping manually is not that hard. It provides compile time type safety checks as well as security.
This is not something you should be doing in any language. It is like eval(), you really should not use it because it can be incredibly dangerous and cause unpredictable things to happen.
They don't all have the same signature
If they don't all have the same signature, how do you plan to call them? You could use the reflect package, but that is normally an indication that you are doing something wrong.
This is not a dynamic language and some things can not be done in Go. Although, they are mostly things you should not do in most languages anyways.
There's no way to dynamically look up a function by name, but I think it's worth mentioning why. Basically, the reason is so that the compiler and/or linker can eliminate unused functions.
Consider that if you were able to get a function by name, then every function in every imported package (recursively) would have to be linked into the final executable, even if it was never used, just in case someone wanted to look it up by name. People already complain about the large size of Go binaries, but this would cause them to be much larger still.
Related
When a struct implements multiple interfaces what is the simplest way to match all of them in a function?
The way go's switch works the following function is not an option.
func f(i interface{}) {
switch i.(type) {
case A:
fmt.Println("A")
case B:
fmt.Println("B")
}
}
Even if i implements both interfaces f(i) outputs only A. Adding fallthrough won't help either. So is there a way to check for multiple interfaces?
You can use a type assertion instead of a switch statement to check whether an interface variable matches a specific interface. If you want to check multiple interfaces, you can use a sequence of multiple type assertions:
func f(i interface{}) {
if _, ok := i.(Aer); ok {
fmt.Println("A")
}
if _, ok := i.(Ber); ok {
fmt.Println("B")
}
}
(https://play.golang.org/p/6aJxV_j9oqy)
It's not at all clear what your purpose is here; as Adrian notes in comments, this isn't something you would normally find in code.
You might find something like this in some sort of debug system, where you want to print information about a variable of some interface type to see what interface(s) it implements. Debuggers generally have direct access to the internal types. In Go specifically, a debugger could use the reflect system here. reflect is deliberately a little bit weaker than debuggers tend to need, but for this particular case, it provides what you might want: you could have a loop that runs through different interface types and invokes reflect.Type.Implements on them.
The type assertion in bcmills' answer is more efficient but less generalizable: if you're doing your own mini-debugger, you might want to provide a table of potential interface types to a function that prints an interface value. (If you were building a real debugger, you would not want anything this inefficient, you'd want to reach directly into the type system's guts and read out the raw tables....)
I've been learning Go and one thing that stood out as particularly interesting to me is the way that the behavior of type assertions changes based on how many return values are being captured:
var i interface{} = "hello"
val, ok := i.(int) // All good
fmt.Println(val, ok)
val = i.(int) // Panics
fmt.Println(val)
This feels like a pattern that can be very useful for user defined functions. The user either has to explicitly get the "ok" second return value or use an underscore to ignore it. In either case, they're making it clear that they're aware that the function can fail. Whereas if they just get one return value, it could silently fail. Hence, it seems reasonable to panic or similar if the user isn't checking for an error (which would be reasonable if the error should "never" happen). I assume that's the logic behind the language developers in making type assertions work this way.
But when I tried to find out how that could be done, I found nothing. I'm aware that type assertions aren't an actual function. And many languages with multiple return values can't check how many return values are actually being used (MATLAB is the only one I'm aware of), but then again, most of those don't use behavior like the type assertions demonstrate.
So, is it possible and if so, how? If not, is there a particular reason that this behavior was excluded despite it being possible with the built in type assertions?
Sadly they cannot be used in normal functions. As far as i know only type assertions, map value access and range allow it.
Usually when you want to have a function with one and optional a second error argument you name them like
func DoSomething() (string, error) {...} // i will return an error
func MustDoSomething() string {...} // i will panic
An example would be https://golang.org/pkg/regexp/#MustCompile
This answer: https://stackoverflow.com/a/41816171/10278 by #christian provides the best practical advice for how to emulate the "overloaded-on-result-count" pattern.
My aim is to address another part of the question—this part: "But when I tried to find out how that could be done, I found nothing".
The following explains how it is done for Go type assertions.
Invocations of type assertions in Go behave as though they are overloaded based on number of results.
Yet, Go does not support overloading of methods and operators.
Looking at Go's implementation, here is the reason type assertions appear to be overloaded based on number of results:
The Go compiler provides special handling that is peculiar to these built-in operations.
This special dispatching occurs for the built-in concept of type assertions because the compiler is carving out special logic that is not available to non-built-in code.
The Go compiler and runtime are written in Go. That made it (somewhat) easy for me to discover that the compiler is the key to explaining this behavior.
Take a look at this part of the compiler:
https://github.com/golang/go/blob/8d86ef2/src/cmd/compile/internal/gc/ssa.go#L4782
The code comment already reveals a lot:
// dottype generates SSA for a type assertion node.
// commaok indicates whether to panic or return a bool.
// If commaok is false, resok will be nil.
We can go further by using a debugger to step through some type assertion code.
Take this playground snippet for example. Specifically, these lines:
object_as_closer_hardstop := thing.(io.Closer) // will panic!!
object_as_closer, ok := thing.(io.Closer)
(If you build Go from source, then) if you use a debugger to step into the first type assertion, you will end up at the following code in the Go runtime:
https://github.com/golang/go/blob/8d86ef2/src/runtime/iface.go#L438
If you step into the second one, you end up at:
https://github.com/golang/go/blob/8d86ef2/src/runtime/iface.go#L454
On line 438, you see func assertI2I (with a single return value). A bit lower, on line 454, you see assertI2I2. Note that these two functions have nearly identical names, but not quite!
The second function has a trailing 2 at the end of its name. That function also has two returned results.
As we expect:
assertI2I can panic, but
assertI2I2 cannot.
(Look at the function bodies in iface.go and note which contains panic.)
assertI2I and assertI2I2 abide by the overloading rules we expect. If they were to differ only by number of results, then those of us who compile Go from source would be unable to compile the Go runtime, due to a compiler error such as "assertI2I redeclared".
Users of the language are generally not aware of these builtin runtime functions, so on the surface, both lines of code seem to call the same function:
object_as_closer_hardstop := thing.(io.Closer) // will panic!!
object_as_closer, ok := thing.(io.Closer)
However, at compile time the compiler branches based on whether it found the case "commaok":
https://github.com/golang/go/blob/8d86ef2/src/cmd/compile/internal/gc/ssa.go#L4871
Our own end-user code does not get to modify Go's lexing/parsing/AST-walking in order to dispatch different flavors of our functions based on "commaok".
For better or for worse, that is why user-written code cannot leverage this pattern.
I have a struct in one package that has private fields:
package foo
type Foo struct {
x int
y *Foo
}
And another package (for example, a white-box testing package) needs access to them:
package bar
import "../foo"
func change_foo(f *Foo) {
f.y = nil
}
Is there a way to declare bar to be a sort of "friend" package or any other way to be able to access foo.Foo's private members from bar, but still keep them private for all other packages (perhaps something in unsafe)?
There is a way to read unexported members using reflect (in Go < 1.7)
func read_foo(f *Foo) {
v := reflect.ValueOf(*f)
y := v.FieldByName("y")
fmt.Println(y.Interface())
}
However, trying to use y.Set, or otherwise set the field with reflect will result in the code panicking that you're trying to set an unexported field outside the package.
In short: unexported fields should be unexported for a reason, if you need to alter them either put the thing that needs to alter it in the same package, or expose/export some safe way to alter it.
That said, in the interest of fully answering the question, you can do this (and have to do it this way in Go >= 1.7)
func change_foo(f *Foo) {
// Since structs are organized in memory order, we can advance the pointer
// by field size until we're at the desired member. For y, we advance by 8
// since it's the size of an int on a 64-bit machine and the int "x" is first
// in the representation of Foo.
//
// If you wanted to alter x, you wouldn't advance the pointer at all, and simply
// would need to convert ptrTof to the type (*int)
ptrTof := unsafe.Pointer(f)
ptrTof = unsafe.Pointer(uintptr(ptrTof) + uintptr(8)) // Or 4, if this is 32-bit
ptrToy := (**Foo)(ptrTof)
*ptrToy = nil // or *ptrToy = &Foo{} or whatever you want
}
This is a really, really bad idea. It's not portable, if int ever changes in size it will fail, if you ever rearrange the order of the fields in Foo, change their types, or their sizes, or add new fields before the pre-existing ones this function will merrily change the new representation to random gibberish data without telling you. I also think it might break garbage collection for this block.
Please, if you need to alter a field from outside the package either write the functionality to change it from within the package or export it.
Edit2: Since you mention White Box testing, note that if you name a file in your directory <whatever>_test.go it won't compile unless you use go test, so if you want to do white box testing, at the top declare package <yourpackage> which will give you access to unexported fields, and if you want to do black box testing then you use package <yourpackage>_test.
If you need to white box test two packages at the same time, however, I think you may be stuck and may need to rethink your design.
I assume what you're testing is a package functionality that changes the state of that package's object, but you want to verify the internals post that change to affirm the new state is correct.
What might help would be writing Get and Set function for the private fields, so they can be accessed beyond the package scope.
package foo
type Foo struct {
x int
y *Foo
}
func (f *Foo) GetY() *Foo {
return f.y
}
func (f *Foo) SetY(newY *Foo) {
f.y = newY
}
Note that the idea of these Get and Set is to limit read and/or write access to the fields, while directly exporting them gives them read+write access automatically always. A subtle difference but worth consideration if the true goal is to only read the private fields and not operate on them (which the package internals would do in there own way)
Finally, if you're not comfortable with adding these type of wrappers for all the private fields in your package, then you can write them in a new file within that package and use build tags to ignore it in your regular builds, and include it in your test builds (wherever/however you trigger your testing).
// +build whitebox
// Get() and Set() function
go test --tags=whitebox
Regular builds ignore building test files along with them, so these wont come in your final binary. If this package is used elsewhere in entirely different ecosystem, then this file wouldn't be built still because of the build tags constraint.
I am just starting out with C++ -> Go porting and I ran across a pair of classes that were friends with each other. I am pretty sure if they are part of the same package they are friends by default, effectively.
The upper case first letter for an identifier is bound within the package. Thus they can be in separate files so long as they are in the same directory, and will have the ability to see each other's unexported fields.
Using reflect, even if it is Go stdlib, is something you should think always carefully about. It adds a lot of runtime overhead. The solution would be basically copy&paste if the two struct types you want to be friends, they simply must be in the same folder. Otherwise you have to export them. (Personally I think the woo woo about the 'risk' of exporting sensitive data is quite overblown, although if you are writing a solitary library that has no executable, maybe there can be some sense to this since users of the library will not see these fields in the GoDoc and thus not think they can depend on their existence).
Internal fields are in principle not exported from a package, which allows the author of a package to freely modify its internals without breaking any other package. Working around this using reflect or unsafe is not a good idea.
The language does deliberately not help you achieve what you want, so you're going to have to do it yourself. The simplest one is to simply merge the two packages — this is what Go unit tests typically do.
The alternative is to create an extra accessor that is only used by the bar package:
// SetYPrivate sets the value of y. This function is private to foo and bar,
// and should not be used by other packages. It might go away in future releases.
func (foo *Foo) SetYPrivate(y int) {
foo.y = y
}
An example of this technique is the runtime.MemStats function in the standard library, which returns a bunch of privates of the GC implementation.
There are multiple "hacks" to get there. One is using go:linkname. Another solution would be to have a public setter and inspect the stack trace.
Ok, I have to admit, I don't really use Go very much at all, but I did just observe something that strikes me as odd for a language that strives for minimality and all that good stuff as Go does. I would be surprised if there isn't a legitimate rationale behind it, so that's what I'm looking for.
So when you have a method, you define it like this:
func (s *SomeStruct) Foo(x int) { }
but why have an extra parameter list just for the "receiver", as I think it's called? Would it not be a simpler and more elegant design to just do
func Foo(s *SomeStruct, x int) { }
and then have s.Foo(5) just be translated to a call to a function Foo(s, 5)?
Methods are fundamentally special and different from regular functions.
Methods must live in the same package as the receiver type.
Methods are used to satisfy interfaces.
Receiver parameters are the only parameters which may be overloaded.
When anonymous struct fields have methods, those methods are "inherited".
With your proposal, the line between a function and a method becomes very blurry and it's difficult to figure out how to resolve the above issues.
That said, I think it would be really interesting to design a language with multimethods and interfaces. However, that language would not be Go.
Your question correctly points out that any method is a function. However, the Go language needs to be able to explicitly distinguish between methods and functions. The reason for this is that methods have features that functions do not have. The choice of whether Foo is a function or a method needs to be made by the programmer.
Go's minimalism means that the language defines only a small set of keywords. The Go authors could have chosen a new keyword, such as method, to distinguish methods from functions:
method Foo(receiver *T, arg1 int) {} // 'Foo' is a method, not a function
Looking around the Go programming language, we can see that the philosophy is to reuse already existing keywords rather than to have a separate keyword for each occasion. The for keyword is a good example of this approach:
for {} // Infinite loop
for a>0 {a--} // A while-do loop
for i := range channel {} // Receive values from a channel
for i:=0; i<N; i++ {} // C-style for loop
The basic idea is that for the parser (and Go programmers) to distinguish the various types of for loops from each other, there is no need to introduce a new keyword if the options can be distinguished by the syntax of what comes after the for keyword: ; := range identifier ..., their sequential order, and their presence/absence.
The func keyword follows the same pattern. It can be used in multiple contexts:
function definitions: func f() {}
function types: type F func(int) int
method definitions: func (t T) SomeMethod() {}
closures: { ...; go func(){c<-1}(); ...}
From minimalism viewpoint, a single func keyword is both simpler and more elegant than having multiple keywords.
The extra parameter list just for the receiver
func (t *T) Foo(x int) {}
enables the parser to distinguish methods and functions:
func IDENTIFIER ... This is going to be a function
func ( ... This is going to be a method
Thus, the parser (as well as Go programmers) can make the distinction based on whether the func keyword is followed by an identifier or by (.
The proposed replacement is not semantically identical to the current state, i.e. it's not a syntactic change only. It will [attempt to] automagically create methods of any [local package] type that happens to be the first parameter of a function. Considering how fundamental method sets are wrt to Go's concept of automatic interface satisfaction rules, this will quite probably lead to a big big mess.
In short, I think such change to the Go language improves nothing while damaging a lot of it's nice features related to methods and interfaces.
Probably because go isn't Python.
Also, because a function declared this way is not a method.
You cannot declare a method outside the object package. So I guess the main rationale in the syntax difference between methods and functions is to be able to differentiate them.
Is the convention for naming slices in Go? Specifically, do you use plurals?
I've noticed that Go App Engine doesn't (eg. it uses key not keys):
func GetMulti(c appengine.Context, key []*Key, dst interface{}) error
I haven't seen anything equivalent in the standard packages or docs I've read. Is singular or plural normal?
That should be a typo, I guess.
Names of slices and arrays are plural. It's not hard to find some samples in the standard library: function SetCookies in CookieJar, Readdirnames, or Args variable in the variables of os package.
But for any variable use a name that better explains its purpose.
A clear exception to this all-plural approach is argv which had its name for decades.
#Mostafa is right. Names of slices and arrays in Go should be a plural. fns is the plural of fn in this example from #Ainar-G. See https://stackoverflow.com/a/35648660/12817546..
package main
import "fmt"
func main() {
var fns []func()
fns = append(fns, beeper)
fns = append(fns, pinger)
for _, fn := range fns {
fn() //beep-beep ping-ping
}
}
func beeper() { fmt.Println("beep-beep") }
func pinger() { fmt.Println("ping-ping") }
#Mostafa is also right that names should explain their purpose. To add to this, self-evident names make code more readable. Self-evident names comment on and document their code.
Self-evident names are consistent. That is they are easy to guess.beeper matches "beep-beep". Self-evident names are accurate. That is they are easy to understand.fns matches fn which denotes a func.
Self-evident names are short. That is they are easy to type. Short names require a short distance between their declaration and their use. Arguments such as fn can be one or two characters-long. For everything else a short one word noun can be used. But sometimes if the distance is great more explanation is needed. A multi-word name mixedCaps can be used. But don't use an under_score_name.
The names used may not be as self-evident as they could be. As a result code may have too many // line comments. Comments can make code less readable. Rename your identifiers so they become more self-evident. And then the number of // can be reduced without loss of explanation.
There are other limits to the use of names. Go keywords cannot be used. Canonical Read, Write, Close, Flush, String etc words should not be used. The first character of a name must be a Unicode letter or a _. Remember capitalized names such as MixedCaps can be exported and type identifiers are typically uppercase.
To find out more have a look at https://talks.golang.org/2014/names.slide, https://blog.golang.org/package-names, https://talks.golang.org/2013/bestpractices.slide, https://golang.org/ref/spec#Identifiers and https://golang.org/doc/effective_go.html#names.