So I'm brand new to Go, I am moving over from python b/c of concurrecny.
Anyways I was looking at the net/http package documentation and stumbled upon this:
client := &http.Client{
CheckRedirect: redirectPolicyFunc
}
So I see we are creating a client variable by referencing the original Client structure (I think that is how you would word that) but I am totally lost at the
CheckRedirect: redirectPolicyFunc
What the heck does the ":" mean and what are we doing with it? Also what are the things before and after it? I read the struct documentation and did the introduction to go tutorial but I didn't see anything, I may not of been looking hard enough. No doubt its simple I just have no idea where to start looking for answers.
Thanks for the answers everyone! This makes much more sense now!
This is called a composite literal.
You're just creating an instance of the http.Client type and setting the
CheckRedirect property, then taking a pointer of it.
Related
Disclaimer: yes I know that this is not "supposed to be done" and "use interface composition and delegation" and "the authors of the language know better". However, I am confronted with a choice of either copy-pasting from the standard library and creating my own packages, or doing what I am asking. So please do not reply with "What you want to do is wrong, you are a bad dev and you should feel bad."
So, in Go we have the http stdlib package. This package has a number of functions for dealing with HTTP Range headers and responses (parsers, a struct for "offset+size" and so forth). For various reasons I want to use something that is very similar to ServeContent but works a bit differently (long story short - the amount of plumbing needed to do the ReaderAt gymnastics is suboptimal for what I want to accomplish) so I want to parse the HTTP Range header myself, using the utility functions/structs from the http stdlib package and then deal with them manually. Basically, I want a changed version of ServeContent :-)
Is there a way for me to "reopen" the http stdlib package to use it's unexported identifiers? ABI is not a concern for me as the source is mine, the program gets compiled from scratch every time etc. etc. and it does not need binary compatibility with older/other Go versions. I.e. I am able to ensure that the build is going to be done on a specific Go version and there are tests to check that an unexported identifier disappeared. So...
If there is a package called foo in the Go standard library, but it only exposes a MagicMegamethod that does the thing I do not need, and uses usefulFunc and usefulStruct that I want to get access to, is there a way for me to get access to those identifiers? Either by reopening the package, or using some other way... that does not involve copy-pasting dozens of lines from stdlib without tests etc.
There exist (rather gruesome) ways of accessing unexported symbols, but it requires nontrivial amounts of tricky code, so there's unlikely to be a net win.
Since you've outruled the "don't do this" direction, it seems that the answer is either NO or use the methods described in the post I linked to (and this repo).
FWIW I'd personally just copy the code I need from the standard library and tweak it to my needs. This would likely take less time than the time it took you to write this SO question :-)
I'm doing the Tour of Go, and this part "Slices are like references to arrays." I haven't changed this code at all so I'm curious as to why it's running out of memory.
It's shouldn't crush, probably something is wrong with the tour website for few moments...
any way for now,
Does anyone know where there is a good example of how to use the asn1 Marshal and Unmarshal funcs in Go?
I'm familiar with the concept of how DER encoding with ASN.1 works, but do not have experience dealing with it directly in code (usually I'm using another library with wraps it - openldap or whatever).
Yes, I've looked at the documentation (http://golang.org/pkg/encoding/asn1/), which seems to describe a tagging system much like what is available for JSON and XML in Go; however I have yet to find a good practical example of this anywhere for the encoding/asn1 package. (Hm, okay I see the Certificate example in asn1_test.go - anyone know of anything else?)
(Overall, I'm trying to implement a very small subset of LDAP (the server side) in Go.)
UPDATE: My question is flawed by the fact that LDAP uses BER, not DER. So encoding/asn.1 isn't going to help. In any case, I ended up making this: https://github.com/bradleypeabody/godap (which uses this for BER+ASN1: https://github.com/go-asn1-ber/asn1-ber )
https://web.archive.org/web/20160816005220/https://jan.newmarch.name/go/serialisation/chapter-serialisation.html
and
https://ipfs.io/ipfs/QmfYeDhGH9bZzihBUDEQbCbTc5k5FZKURMUoUvfmc27BwL/dataserialisation/asn1.html
have quite a few examples with asn1.Marshal / asn1.Unmarshal
package demo
type People struct {
Name string
Age uint
}
type UserInfo struct {
Address string
Hobby []string
NickNage string
}
another package:
import "demo"
in this package, how can I get all the types exported from the demo package?
Using go/importer:
pkg, err := importer.Default().Import("time")
if err != nil {
fmt.Println("error:", err)
return
}
for _, declName := range pkg.Scope().Names() {
fmt.Println(declName)
}
(note, this returns an error on the Go Playground).
Go retains no master list of structs, interfaces, or variables at the package level, so what you ask is unfortunately impossible.
Drat, I was hoping that Jsor's answer was wrong, but I can't find any way to do it.
All is not lost though: If you have the source to 'demo', you could use the parser package to fish out the information you need. A bit of a hack though.
Do you come from some scripting language? It looks so.
Go has good reasons to propagate to let not slip 'magic' into your code.
What looks easy at the beginning (have access to all structs, register them automatically somewhere, "saving" coding) will end up in debugging and maintenance nightmare when your project gets larger.
Then you will have to document and lookup all your lousy conventions and implications.
I know what I am talking about, because I went this route several times with ruby and nodejs.
Instead, if you make everything explicit you get some feature, like renaming the People struct to let
the compiler tell you where it is used in your whole code base (and the go compiler is faster than you).
Such possibilities are invaluable for debugging, testing and refactoring.
Also it makes your code easy to reason about for your fellow coders and yourself several months after you have written it.
What do you believe in? As an incomplete basis for a good product - would you prefer a mess of code that is horrible to look at but works perfectly for what its supposed to do, or a beautiful set of well organized classes (or something else if OO doesn't float your boat) but have buggy functionality that still needs a lot of work?
If you were just handed a project to improve and work towards completion, which would you prefer? And what do you put the emphasis on when starting a new project?
Well written code will be easier to debug. If the code is too messy, even if it has "no bugs" (unlikely) it will not be maintainable.
I prefer both. However, if I was going to be handed a project I would go with buggy but beautiful everytime.
If we're talking about abstractions, I'd prefer to have just a small base set of working features. While it might be nice to have a pre-built, working library on top of this, the user can always create greater functionality from that working base.
Maybe they don't look nice, but again, a user can always just create a wrapper to make things look nice. I vote function.
Real artists ship - so something, that is both beautiful and gets the job done. But when in doubt, err on the "gets the job done" side, even if it isn't perfection.