Skip to content

Remove use of default args from StyleTypes - #62

Merged
davesmith00047 merged 2 commits into
mainfrom
minor-refactoring-of-style-types
Oct 1, 2025
Merged

Remove use of default args from StyleTypes#62
davesmith00047 merged 2 commits into
mainfrom
minor-refactoring-of-style-types

Conversation

@davesmith00047

Copy link
Copy Markdown
Collaborator

No description provided.

@davesmith00047 davesmith00047 self-assigned this Sep 30, 2025
@davesmith00047

Copy link
Copy Markdown
Collaborator Author

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 apply methods that give you valid combinations, where your IDE can give you hints as to what good and useful combinations are available. It isn't perfect, but it works for me. I also usually try to order the arguments from most of the least interesting / common, so that most people just use one or two arguments out of a possible 4, say. Also if there are internal arguments or lots of arguments, then you can just expose a curated list of good combinations to the user.

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:

  1. Point
  2. Signal
  3. BoxShadow

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.

@davesmith00047
davesmith00047 merged commit c3057bb into main Oct 1, 2025
1 check passed
@davesmith00047
davesmith00047 deleted the minor-refactoring-of-style-types branch October 1, 2025 08:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants