I have a function in go that I want to provide it to others(in other Go programs on unix servers). However, I don't want them to know the implementation so I can not just give them the source code. I've check out the c-shared buildmode but it seems troublesome because of all the conversions between C types and Go. I wonder if there are simpler ways like
lib := load(somelib)
res := lib.somefunc(args)
Related
As I come from a C and C++ background and golang is semantically different I have some discussions about function names "New" vs "Open" and what the programmer expects what to happen under the hood. I have created a package where the New function opens file descriptors to temporary files. I'm not sure this is intended behavior for APIs written in Go.
Here is a snippet:
// Not directly convenient New allocates file descriptors
deb := New()
deb.AddFile("/tmp/myfile")
deb.Write("/tmp/mypackage.deb")
deb.Close()
// Idiomatic it opens file descriptors but we have to provide context to open
info := &Props{Name: "mypackage"}
deb := info.Open("/tmp/mypackage.deb")
deb.AddFile("/tmp/myfile")
deb.Close()
Go's community is still finding its idioms and patterns, so don't consider anything dogma. Based on what I've seen in a year and a half, I don't think it's wrong to touch disk in a New function if it has godoc comments explaining the behavior. It would be unusual, and probably make more sense to touch the disk in d.Write(). Some common patterns I've seen with New functions:
are only exported when designed for use by other packages
makes sense when invoked from other packages with the package name prefixed: d := deb.New(...) (since you have a variable named deb, your package is something else)
returns an instance of the package's main business logic, to be used further
accept dependencies as arguments instead of constructing its own dependencies (hopefully any behavioral dependencies are interfaces)
often a main() function assembles those dependencies, calls d := deb.New(deps), and executes the behavior d.AddFile(); d.Write(); d.Close()
an example signature using an interface:
package deb
// New accepts blah returning a *Deb. It returns nil if blah.
func New(name string, to io.WriteCloser) *Deb {...}
I really like Go but makes me crazy about if-err hell and when I have sync datatypes in Go code with other languages. For C/C++ I can easily deal such stuff with macros, while Go developers say the idiomatic solution for Go is code generation, but I didn't find any out-of-the-box solution.
So basically, what I need is something like
Read the source, for every type usage check if it is listed in special config file. If it is, then change it with the one from config.
Read the source, for every function check if it is listed in config file. If it is then, change it with the code snippet from config by template and add neccessary import if it's missing.
Probably, add some polymorphism based on return values to prevent type casts.
Maybe, add (err error) logic. Not sure it's a good idea.
Like this
code.go
func getConn(id platform.UUID) (res1 string, res2 platform.res) {
res1 = driver_native_res(id)
res2 = driver_native_res(id)
return
}
code-gen.go
import (
"linux"
)
func getConn(id uint64) (res1 string, res2 int32, err error) {
res1, err = linux.GetResAsString(id)
if err != nil {
return
}
res2, err = linux.GetRes(id)
if err != nil {
return
}
return
}
I know about go AST, but seems like it's not very fast to implement such features with it. I hope there is some easier solution.
As you have discovered, there are no macros and are unlikely to be. There may be generics at some point which could be helpful. In the meantime, there are a few options for code generation. You can use go generate for this:
// add a magic comment to your go file
// which needs some extra generated code
// this calls a tool called stringer to generate,
// but it could be yacc or some homemade tool.
//go:generate stringer -type=Pill
// call go generate to generate the methods:
go generate
https://blog.golang.org/generate
But it really requires you to have a tool to generate the code you want like stringer.
Or you could just use text/template, build your own template, and run a simple tool that substitutes values into this template (from a config file, or perhaps arguments on the command line).
mytool generate -type=thing -field=type...
... mytool loads a tmplate file,
runs it through text/template and outputs it.
This is pretty straightforward and you could easily build a custom system with it, though you'll probably want to generate once, then use the code. Here are some examples of this approach:
http://clipperhouse.github.io/gen/
https://github.com/fragmenta/fragmenta
Finally, you can use tools like grpc which generate structs in multiple languages in order to ease cross-language communication, which sounds like exactly the use case you are looking for:
https://grpc.io/docs/quickstart/go.html
I'd look at something like grpc first.
I'm trying go for a small project and tried to write these functions:
func fatal(reason string) {
println(reason)
os.Exit(1)
}
func fatal(err error) {
fatal(err.Error())
}
After digging about a bit and finding this answer, which referenced the docs on overloading I realised that what I was trying to do was illegal in go.
What I want is a simple api that allows me to call fatal with either a string or an error in order to simplify my logic. How do I achieve this or a similar goal?
It would feel inelegant to have func fatal(reason string) along with func fatalErr(err error), is that what's needed? Am I missing a different feature of the language that allows me to do what I want?
The most common way to do this would be to define the method as func fatal(err interface{}) then do type assertions or use a type switch within it's body to handle each of the different types. If I were coding for your example it would look like this;
func fatal(err interface{}) {
if v, ok := err.(string); ok {
fmt.Println(v)
}
if v, ok := err.(error); ok {
fmt.Println(v.Error())
} else {
// panic ?
}
}
Also; here's a quick read about type switches and assertions that may be helpful; http://blog.denevell.org/golang-interface-type-assertions-switch.html
You can also check out effective-go as it has sections on both features.
Use log.Fatal() instead. https://golang.org/pkg/log/#Fatal
You can use interface{} but it is not recommended because you lose all the benefits of type checking when you do that. The Go authors get to use interface{} because they understand the appropriate level of additional testing and checks to do when using interface{}. It's much easier (even for intermediate and advanced gophers) to use builtin and standard library functions when something like this is required.
Go does not have algebraic or/sum types either. The standard workaround is to define an and/product type with pointers (e.g. struct{*string, *error}) and go to the effort of making sure you only ever make one of the fields non nil at any point in time.
Function overloading is not supported in the language. From the official Golang site it says,
Method dispatch is simplified if it doesn't need to do type matching as well. Experience with other languages told us that having a variety of methods with the same name but different signatures was occasionally useful but that it could also be confusing and fragile in practice. Matching only by name and requiring consistency in the types was a major simplifying decision in Go's type system.
Regarding operator overloading, it seems more a convenience than an absolute requirement. Again, things are simpler without it.
https://golang.org/doc/faq#overloading
One potential solution would be to define a high level function that type checks and handles different types similarly to how you would overload multiple functions. See #evanmcdonnal's solution for a great example.
I know this might be controversial or not very broad but I'm going to try to be very specific and relate to other questions.
Ok so when I make a Go program what things should I be thinking in terms of how I should organize my project? (E.g. should I think ok I'm going to have controllers of some sort so I should have a controller subdirectory that's going to do this so I should have that)
How should I structure a package?
For example the current program I'm working on I'm trying to make a SteamBot using this package
But while I'm writing it I don't know if I should export certain methods into their own own files, e.g. I'd have something like
func (t *tradeBot) acceptTrade() {}
func (t *tradeBot) declineTrade() {}
func (t *tradeBot) monitorTrade() {}
func (t *tradeBot) sendTrade() {}
each method is going to have quite a bit of code so should I export each method into its own file or just have 1 file with 3000 lines of code in it?
Also using global variables so that I can set one variable and then leave it and be able to use it in multiple functions, or is this bad and I should pass the variables as arguments?
Also should I order my files like:
package
imports
constants
variables
functions
methods
Or do I just put things where I need them?
The first place to look for inspiration is the Go standard library. The Go standard library is a pretty good guide of what "good" Go code should look like. A library isn't quite the same as an application, but it's definitely a good introduction.
In general, you would not break up every method into its own file. Go tends to prefer larger files that cover a topic. 3000 lines seems quite large, though. Even the net/http server.go is only 2200 lines, and it's pretty big.
Global mutable variables are just as bad in Go as in any language. Since Go relies so heavily on concurrent programming, global mutable variables are quite horrible. Don't do that. One common exception is sync structures like sync.Pool or sync.Once, which sometimes are package global, but are also designed to be accessed concurrently. There are also sometimes "Default" versions of structures, like http.DefaultClient, but you can still pass explicit ones to functions. Again, look through the Go standard library and see what is common and what is rare.
Just a few tips that you hopefully find useful:
Organize code into multiple files and packages by features, not by layers. This becomes more important the bigger your application becomes. package controllers with one or two controllers is probably ok, but putting hundreds of unrelated controllers in the same package doesn't make any sense. The following article explains it very well: http://www.javapractices.com/topic/TopicAction.do?Id=205
Global variables sometimes make code easier to write however they should be used with care. I think unexported global variables for things like logger, debug flags, etc are ok.
Where in Go's source code can I find their implementation of make.
Turns out the "code search" functionality is almost useless for such a central feature of the language, and I have no good way to determine if I should be searching for a C function, a Go function, or what.
Also in the future how do I figure out this sort of thing without resorting to asking here? (i.e.: teach me to fish)
EDIT
P.S. I already found http://golang.org/pkg/builtin/#make, but that, unlike the rest of the go packages, doesn't include a link to the source, presumably because it's somewhere deep in compiler-land.
There is no make() as such. Simply put, this is happening:
go code: make(chan int)
symbol substitution: OMAKE
symbol typechecking: OMAKECHAN
code generation: runtime·makechan
gc, which is a go flavoured C parser, parses the make call according to context (for easier type checking).
This conversion is done in cmd/compile/internal/gc/typecheck.go.
After that, depending on what symbol there is (e.g., OMAKECHAN for make(chan ...)),
the appropriate runtime call is substituted in cmd/compile/internal/gc/walk.go. In case of OMAKECHAN this would be makechan64 or makechan.
Finally, when running the code, said substituted function in pkg/runtime is called.
How do you find this
I tend to find such things mostly by imagining in which stage of the process this
particular thing may happen. In case of make, with the knowledge that there's no
definition of make in pkg/runtime (the most basic package), it has to be on compiler level
and is likely to be substituted to something else.
You then have to search the various compiler stages (gc, *g, *l) and in time you'll find
the definitions.
As a matter of fact make is a combination of different functions, implemented in Go, in the runtime.
makeslice for e.g. make([]int, 10)
makemap for e.g. make(map[string]int)
makechan for e.g. make(chan int)
The same applies for the other built-ins like append and copy.