3 ms·
The lack of default argument values initially annoyed me, but I kind of came to like it. It makes me put more thought into my function interfaces. In the rare
by donatj 2y ago
The lack of default argument values initially annoyed me, but I kind of came to like it. It makes me put more thought into my function interfaces.
In the rare cases I do want a default it's usually reasonable to just add a second function that calls the first with the default value.
I don't end up doing this a lot, but I certainly have in a couple handful of cases. A lot of Go libraries for HTTP related activities do this with the default context. They'll have a function that accepts a context and a function that has the default context.
Example
https://github.com/slack-go/slack/blob/242df4614edb261e5f4f4a3907c979caf6b4977c/users.go#L252 https://github.com/slack-go/slack/blob/242df4614edb261e5f4f4...
Honestly, with good naming, I think this is just generally more readable and expectable behavior only takes three lines of code.
- mrj 2y agoSure, one can make a new function. That's what I do, too, but then I end up greatly missing function overloading. In the example's case I might end up making a ReplaceAll function. It creates namespace clutter. Function overloading could easily handle context with and without arguments.
- enneff 2y agoI think if there are a lot of functions (or a function with a lot of arguments, common to python) you have clutter regardless. I would rather have a bunch of different names than a bunch of different functions with the same name. Having to choose names for each of the functions is a gentle push back asking “do you really need all these flavours of function or are you abstracting this in the wrong way?”
- wild_egg 2y agoFWIW a lot of those packages with default context wrapper functions have that as a backwards compatibility measure for code written before the context package existed. It's almost always preferable to call the newer function with your own context instead