Remove use of default args from StyleTypes - #62
Conversation
|
Question from @slemus9 (paraphrased), answering here in case anyone else is wondering: "What's wrong with default arguments and why use apply methods instead?" The problem with default arguments (classically, but possibly not in this case!) is that you can end up with invalid combinations of arguments, or arguments that produce unexpected results (this issue should be google-able / chatgpt-able). For this reason, default args are usually considered bad practice. Mostly I think default arguments are bad on functions and methods. Is this really true on pure data types and their constructors? ...I could be persuaded that it isn't. 🙂 However, a modern example where you can see default args causing confusion is in my favourite Scala lib: OS-Lib. OS-Lib uses them all over the place and it obscures the available options and makes it more difficult to work out valid combinations. OS-Lib is great, and I love 90% of the API, just not this bit: // Redirect all outputs, just a few of the arguments available to the `call` method.
os.proc("vim").call(stdin = os.Inherit, stdout = os.Inherit, stderr = os.Inherit)The drawback of not allowing default arguments is that you lose the convenience of having them! So my attempt at finding a middle ground is to not use default arguments, but expose My goal with API's and datatypes is to make them as friendly and discoverable as possible, employing builder patterns and other techniques that allow you to get as much mechanical assistance from your IDE as I can. Here's a couple of examples of the lengths I usually go to: If others felt strongly that default arguments in cases like the one in this PR were not a problem, I wouldn't be too upset. In this instance I mostly did the work because by 'cleaning' the code, I'm forced to read it properly. 😄 Hope that helps. |
No description provided.