Following the example in the Rust book using its suggested rand = "0.6.0", I get code that looks like this:
use rand::Rng;
fn main() {
let secret_number = rand::thread_rng().gen_range(1, 101);
println!("The secret number is: {}", secret_number);
}
Everything the book says later on in its chapter on modules suggests that if you do a use rand::Rng; as above, you'll be able to use Rng. If that happens to be a module itself, you can use submodules with Rng::submodule. If that happens to be a type, you just use it as Rng. In the code above however, we never use Rng anywhere.
Instead, we use the seemingly unrelated rand::thread_rng(). From what I understand, since rand is the name of the top level crate, we should be able to use it, even without the use statement that doesn't appear to do anything.
Instead, for some reason, the program will fail to compile without the use statement. This is really confusing. I wish the book did a better job explaining what was happening there.
Why do we need the use statement? Why are we not using Rng? How is it related to rand::thread_rng()?
I come from a Python background, so I'm used to the idea that if you import threading, you're using threading.something. If you import django.utils, you're using django.utils.something. This seems like an import of django.utils where you're using the totally unrelated django.urls.
You cannot call trait methods unless the trait is in scope.
In the code above however, we never use Rng anywhere.
You're using Rng. gen_range() is a trait method defined by the Rng trait so Rng must be in scope for you to call gen_range().
The nitty gritty details: rand::thread_rng() returns ThreadRng which implements RngCore and gets an Rng implementation because of the generic blanket impl impl<R> Rng for R where R: RngCore + ?Sized.
Related
I know this has been asked in various forms many times before but I just can't seem to implement what I'm learning in the way that I need. Any help is appreciated.
I have a series of exchanges which all implement roughly the same APIs. For example, each of them have a GetBalance endpoint. However, some have one or two unique things which need to be accessed within the functions. For example, exchange1 needs to use a client when calling it's balance API, while exchange2 requires both the client variable as well as a clientFutures variable. This is an important note for later.
My background is normal OOP. Obviously Go is different in many ways, hence I'm getting tripped up here.
My current implementation and thinking is as follows:
In exchanges module
type Balance struct {
asset string
available float64
unavailable float64
total float64
}
type Api interface {
GetBalances() []Balance
}
In Binance module
type BinanceApi struct {
key string
secret string
client *binance.Client
clientFutures *futures.Client
Api exchanges.Api
}
func (v *BinanceApi) GetBalance() []exchanges.Balance {
// Requires v.client and v.clientFutures
return []exchanges.Balance{}
}
In Kraken module
type KrakenApi struct {
key string
secret string
client *binance.Client
Api exchanges.Api
}
func (v *KrakenApi) GetBalance() []exchanges.Balance {
// Requires v.client
return []exchanges.Balance{}
}
In main.go
var exchange *Api
Now my thought was I should be able to call something like exchange.GetBalance() and it would use the GetBalance function from above. I would also need some kind of casting? I'm quite lost here. The exchange could either be Binance or Kraken--that gets decided at runtime. Some other code basically calls a GetExchange function which returns an instance of the required API object (already casted in either BinanceApi/KrakenApi)
I'm aware inheritance and polymorphism don't work like other languages, hence my utter confusion. I'm struggling to know what needs to go where here. Go seems to require loads of annoying code necessary for what other languages do on the fly 😓
using *exchanges.Api is quite weird. You're wanting something that implements a given interface. What the underlying type is (whether it's a pointer or a value receiver) is not important, so use exchanges.Api instead.
There is another issue, though. In golang, interfaces are implicit (sometimes referred to as duck-type interfaces). Generally speaking, this means that the interface is not declared in the package that implements it, but rather in the package that depends on a given interface. Some say that you should be liberal in terms of what values you return, but restrictive in terms of what arguments you accept. What this boils down to in your case, is that you'd have something like an api package, that looks somewhat like this:
package api
func NewKraken(args ...any) *KrakenExchange {
// ...
}
func NewBinance(args ...any) *BinanceExchange {
}
then in your other packages, you'd have something like this:
package kraken // or maybe this could be an exchange package
type API interface {
GetBalances() []types.Balance
}
func NewClient(api API, otherArgs ...T) *KrakenClient {
}
So when someone looks at the code for this Kraken package, they can instantly tell what dependencies are required, and what types it works with. The added benefit is that, should binance or kraken need additional API calls that aren't shared, you can go in and change the specific dependencies/interfaces, without ending up with one massive, centralised interface that is being used all over the place, but each time you only end up using a subset of the interface.
Yet another benefit of this approach is when writing tests. There are tools like gomock and mockgen, which allow you to quickly generate mocks for unit tests simply by doing this:
package foo
//go:generate go run github.com/golang/mock/mockgen -destination mocks/dep_mock.go -package mocks your/module/path/to/foo Dependency
type Dependency interface {
// methods here
}
Then run go generate and it'll create a mock object in your/module/path/to/foo/mocks that implements the desired interface. In your unit tests, import he mocks package, and you can do things like:
ctrl := gomock.NewController(t)
dep := mocks.NewDependencyMock(ctrl)
defer ctrl.Finish()
dep.EXPECT().GetBalances().Times(1).Return(data)
k := kraken.NewClient(dep)
bal := k.Balances()
require.EqualValues(t, bal, data)
TL;DR
The gist of it is:
Interfaces are interfaces, don't use pointers to interfaces
Declare interfaces in the package that depends on them (ie the user), not the implementation (provider) side.
Only declare methods in an interface if you are genuinely using them in a given package. Using a central, overarching interface makes this harder to do.
Having the dependency interface declared along side the user makes for self-documenting code
Unit testing and mocking/stubbing is a lot easier to do, and to automate this way
# I want to mock this function
func testCheckPluginFile(fName string){
plugin, _ := plugin.Open(path.Join("/I/expect/folder/","/plugin-lib-test/"+fName))
plugin.Lookup("symbol")
}
# So I put this func like this
func testCheckPluginFile(fName string,pluginOpen func (path string) (*plugin.Plugin, error)){
plugin, _ := pluginOpen(path.Join("/I/expect/folder/","/plugin-lib-test/"+fName))
plugin.Lookup("symbol")
}
But I can't do it beacuse of the plugin.Plugin.lookup
Do u have another way to solve it ?
How to mock [...]plugin funcs in go[...]?
You cannot.
If you want to test that you have to use a real plugin.
Mocking in Golang is a bit tricky, and usually requires to generate some code. You need to write interfaces for the plugin package as well as for plugin.Plugin (if the package does not offer these by itself; something which alas is often the case). Then, use a mock generator (the usual suspect being gomock) to create mocks with all the usual mock functionality (expect, conditional return, etc.). In the production code, provide production implementations which you write yourself; they only consist of simple pass-through methods which call the real thing (Open() and Lookup() in this case). (Remember, you want to test whether testCheckPluginFile works correctly, not whether the plugin package works correctly.) By doing so, you should be able to follow proper TDD workflow.
I'm on my first Golang project, which consists of a small router for an MVC structure. Basically, what I hope it does is take the request URL, separate it into chunks, and forward the execution flow to the package and function specified in those chunks, providing some kind of fallback when there is no match for these values in the application .
An alternative would be to map all packages and functions into variables, then look for a match in the contents of those variables, but this is not a dynamic solution.
The alternative I have used in other languages (PHP and JS) is to reference those names sintatically, in which the language somehow considers the value of the variable instead of considering its literal. Something like: {packageName}.{functionName}() . The problem is that I still haven't found any syntactical way to do this in Golang.
Any suggestions?
func ParseUrl(request *http.Request) {
//out of this URL http://www.example.com/controller/method/key=2&anotherKey=3
var requestedFullURI = request.URL.RequestURI() // returns '/controller/method?key=2key=2&anotherKey=3'
controlFlowString, _ := url.Parse(requestedFullURI)
substrings := strings.Split(controlFlowString.Path, "/") // returns ["controller","method"]
if len(substrings[1]) > 0 {
// Here we'll check if substrings[1] mathes an existing package(controller) name
// and provide some error return in case it does not
if len(substrings[2]) > 0 {
// check if substrings[2] mathes an existing function name(method) inside
// the requested package and run it, passing on the control flow
}else{
// there's no requested method, we'll just run some fallback
}
} else {
err := errors.New("You have not determined a valid controller.")
fmt.Println(err)
}
}
You can still solve this in half dynamic manner. Define your handlers as methods of empty struct and register just that struct. This will greatly reduce amount of registrations you have to do and your code will be more explicit and readable. For example:
handler.register(MyStruct{}) // the implementation is for another question
Following code shows all that's needed to make all methods of MyStruct accessible by name. Now with some effort and help of reflect package you can support the routing like MyStruct/SomeMethod. You can even define struct with some fields witch can serve as branches so even MaStruct/NestedStruct/SomeMethod is possible to do.
dont do this please
Your idea may sound like a good one but believe me its not. Its lot better to use framework like go-chi that is more flexible and readable then doing some reflect madness that no one will understand. Not to mention that traversing type trees in go was newer the fast task. Your routes should not be defined by names of structures in your backend. When you commit into this you will end up with strangely named routes that use PascalCase instead of something-like-this.
What you're describing is very typical of PHP and JavaScript, and completely inappropriate to Go. PHP and JavaScript are dynamic, interpreted languages. Go is a static, compiled language. Rather than trying to apply idioms which do not fit, I'd recommend looking for ways to achieve the same goals using implementations more suitable to the language at hand.
In this case, I think the closest you get to what you're describing while still maintaining reasonable code would be to use a handler registry as you described, but register to it automatically in package init() functions. Each init function will be called once, at startup, giving the package an opportunity to initialize variables and register things like handlers and drivers. When you see things like database driver packages that need to be imported even though they're not referenced, init functions are why: importing the package gives it the chance to register the driver. The expvar package even does this to register an HTTP handler.
You can do the same thing with your handlers, giving each package an init function that registers the handler(s) for that package along with their routes. While this isn't "dynamic", being dynamic has zero value here - the code can't change after it's compiled, which means that all you get from being dynamic is slower execution. If the "dynamic" routes change, you'd have to recompile and restart anyway.
How can I write a Go package that wraps a library such that calls to overridden functions use my implementation, and non-overridden functions "fall through" to the library I am wrapping?
In particular: I want my Go package to wrap net/http, except I initially want to only replace http.FileServer and http.NotFoundHandler, and leave all other functions the same. My library is a drop-in replacement for existing code that calls other net/http functions I won't overwrite. For example, I want to be able to do:
package main
import (
"log"
http "github.com/jstrieb/my-special-http-lib"
)
func main() {
http.ListenAndServe( // Use the net/http ListenAndServe by "falling through" my library
":8080",
http.FileServer(http.Dir("/usr/share/doc")) // Use my custom, overridden http.FileServer
)
}
What I have tried
I could manually override each function exported by the wrapped library (like below), but I would rather avoid this if possible. This approach is undesirable because it doesn't account for instances where functions I override are called from within the library I am wrapping.
func ExportedFunction(input1 type1) type2 {
return http.ExportedFunction(input1)
}
I could also fully fork the net/http source and change it directly, but I want it to be clear what changes I am making without having to compare against the original version. It also doesn't makes sense to maintain a fork of part of the standard library to only override a few functions.
Justification
I am not looking for commentary on whether this is a "good" idea. I just want to know how to do it.
The plan for this library is to simply change the appearance of the 404 page and the directory listing index page. This purely aesthetic change does not affect the underlying functionality or API of net/http. If it was not structured to wrap all of net/http, then a user would have to switch between using two packages to do the same thing. Then my library could not be considered a "drop-in replacement" for code that already uses net/http.
I also intend to override more functions over time, but the API of my library will always match that of net/http. Doing it this way reduces the need to manually replace calls like http.Function with mylibrary.Function every time the library changes. Moreover, I want to be able to import my replacement in code (using net/http) that I did not write, and don't want to manually refactor.
What you are trying to achieve here is extend the functionality of package. Simple answer here is you cannot do so as of now. Best possible way to achieve this is just doing this manually.
Personally I don't see any harm in having two packages seperate. I this it is more maintainable. Just wrap the functions you want to update. Sometimes all you need is a function.
Not a Go expert, but speaking anecdotally, this would introduce a significant vulnerability if by specifying one dependency you were then able to side-load a different version of it instead with whatever modifications you wanted.
It might speak to the notion of, if this dependency is something you can bring into your application, then you should build a library which builds off the one you want to modify, and import that one in instead. That is to say, given your application A and library B, with your modified library B', you would want to write your application such that A depends on B' which depends on B, which would make the relationship apparent. If you wanted to somehow have A depend on B but be able to side-load B' in dynamically, then that would represent the vulnerability that I allude to earlier.
I have a string with name of package (like "my/package/test") and I wanna import that and call some function from package.
Something like this:
func init() {
var pkg string = "test/my/pkg"
import pkg
pkg.Test()
}
PS. Thanks for help
The Go language does not allow what you mentioned in your example. This is a conscious choice. In my opinion, the reason behind this choice has to do with compiler performance and ease of code understanding by the machine. This for example enables tools such as gofix that can partially fix Go code without need for user intervention.
It also enables a programmer to clearly see all of the statically imported packages used by the program.
See also the grammar rules for source file organization in the Go language specification.
In relation to dynamically loading packages at run-time: Go has no support for loading packages at run-time. A future Go run-time might implement this feature (for example, it is occasionally being requested in messages in the golang-nuts mailing list), but the current state is that there is no support for this feature.
That's not possible in Go. The linker has to know the dependencies at compile-time, your string (and the init-function) are however evaluated at run-time. Also note, that parts of your programs which are not used, i.e. everything which isn't referred explicitly, wont even be part of the final binary - so reflection is not possible either.
If you need something like that, you have to manage the mapping on your own. You can for example use a global map in one package and use the init functions in the other packages to register the relevant functions, by adding them to the map. After that, you can use the map to do your look-ups dynamically.
Take a look at the http package for example. In a fictional blog package you might use the blog.init() function to register a couple of http handlers using the http.HandleFunc(pattern, handler) function. The main package then might call http.ListenAndServe() which looks up the right handlers at run-time.