11 ms·
Isn’t that just a consequence of Go’s backwards compatibility guarantee? Adding new arguments to the Mux interface would break existing code, given the method
by avianlyric 3y ago
Isn’t that just a consequence of Go’s backwards compatibility guarantee?
Adding new arguments to the Mux interface would break existing code, given the method signature can’t be changed, these magic strings seem like a reasonable compromise. It not like HTTP verbs are going to change anytime soon, and it’s trivial to validate them during register, or via static analysis. So I’m not sure what value the use of constants would bring, especially if it either broke backwards compatibility, or forced the creation of a new, but slightly different mux API that would have to live in parallel with the old API forever.
- Macha 3y agoSurely the changes to panic on conflicting routes being discussed upstream already prove they're willing to flex on that guarantee?
- barsonme 3y agoThat’s not a breaking change.
- Macha 3y agoHow is "this api usage was allowed before and now panics" not a breaking change?
- avianlyric 3y agoWhich specific API usage was allowed before and now panics? As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice, which in my books is just a bug. Certainly it's technically a breaking change, but there's huge difference between making all existing usage of the mux interface incompatible with the new changes, and only making obviously incorrect and buggy usages of the interface incompatible.
- d-z-m 3y ago> As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice. This has always resulted in a panic[0]. [0]: https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/net/http/server.go;l=2503 https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/ne...
- jiehong 3y agoIsn’t function overloading based on the number of arguments a thing in go? That wouldn’t break compatibility