4 ms·
It's just a design decision of the http library, that its router by default accepts an interface and not a function - so internally you need this little adapter
by dvirsky 13y ago
It's just a design decision of the http library, that its router by default accepts an interface and not a function - so internally you need this little adapter to make the function comply with that interface. I also loved this little trick when I noticed it.
But if the HTTP library would directly accept a function, you could then just pass a function without that trick. Go doesn't mandate you use interfaces for callbacks (like Java did until 1.8), you can also define an API that accepts functions directly, provided they have a certain signature.
Also, the standard library hides this little trick from you, and just exposes the HandleFunc method, that lets you register plain functions as handlers. as in this example: http://golang.org/pkg/net/http/#ListenAndServe http://golang.org/pkg/net/http/#ListenAndServe
- tomp 13y agoIf I understand the Java 8 example correctly, the Http.handle accepts an interface as well (the Handler interface with a single method). Java compiler is smart enough to automatically convert functions into objects satisfying interfaces with exactly one method, while Go compiler isn't.
- dvirsky 13y agoYeah, well, knowing the Go philosophy, it makes sense not to have the compiler solve ambiguities like that, especially since a function can have its own methods.
- colin_mccabe 13y agoUsually you don't want the compiler to be "smart" in this way, because it creates other headaches. For example, is a temporary object created each time you do this? What impact will that have on GC? If I compare an object of this interface with a "fake interface object" generated by the compiler, will it always be the same for the same callback? What is the call stack going to look like when I use jps? Seeing another <<anonymous>> line in there wouldn't give me the warm fuzzies when debugging. I was not a fan of auto-unboxing for ints, for the same reasons. There are a lot of good features in Java 8, but I'm not a fan of this particular one. Even if it saves a line of typing.
- dvirsky 13y agoBTW I don't think the compiler is "smart enough" - but the Http API has 2 (probably more) overloaded methods for each type you may want to pass to it. Go doesn't have method overloading by design. If that's something that is a must have for anyone, Go is simply not for them.
- twic 13y agoNo, it's exactly as tomp says - in Java 8, lambda expressions are handled by compiling them to little classes which implement interfaces. Kind of. The truth is that something absolutely barking mad goes on in the compiler, and then extra magic is injected at runtime: http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html http://cr.openjdk.java.net/~briangoetz/lambda/lambda-transla... But it behaves exactly as if there were little classes which implement interfaces. Just more efficient.
- dvirsky 13y agoOh, thanks for the info, didn't know that. Still I don't think that Go should have that feature.