support chain-calls#59
support chain-calls#59sdbaiguanghe wants to merge 2 commits intogorilla:masterfrom sdbaiguanghe:master
Conversation
|
@elithrar why check failed? what's meaning of the error information (The command "go get golang.org/x/tools/cmd/vet" failed and exited with 1 during),what should i do next? |
|
This is a build error with changes to go vet, not with your code. I'll take a look at your PR tonight. On Tue, Apr 26, 2016 at 2:13 AM sdbaiguanghe notifications@github.com
|
|
Can you write a test for this that demonstrates the usage? Helps prevent regression. Otherwise looks good. |
|
I modified |
|
Technically this breaks the API guarantee if someone has created an interface that |
|
I think it's a pretty unlikely case though, I can't really see a reason to do that apart from in unit tests, and even then... |
|
I'm going to close this. There's really not that much benefit since there's only a few options, and it breaks the public API. |
Since gorillaGH-59 was rejected on the basis that it wasn't useful enough to break the public API. I took a stab at an alternate solution that doesn't break the public API. While still allowing one to configure the decoder when defining it as a package global (as recommended by the README). ```go var decoder = NewDecoder(func(d *Decoder) { d.IgnoreUnknownKeys(true) }) ```
Since gorillaGH-59 was rejected on the basis that it wasn't useful enough to break the public API. I took a stab at an alternate solution that doesn't break the public API. While still allowing one to configure the encoder and decoder when defining it as a package global (as recommended by the README). ```go var decoder = NewDecoder(WithIgnoreUnknownKeysDecoderOpt(true)) ```
could support chain-calls? I think it is more convenient。
Before
After