-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise API #34
Comments
Really great suggestions! I think we can start working on them right away. Do you think it's better to make a big PR by changing everything at once or proceed module by module? |
It might be best to go module by module. If you would like to take the lead on this, I will review, approve, and merge the PRs as they come in. |
Also: if you would like to select a couple of modules to work on, I can then select a few others so as to work in parallel and speed things up. |
Some ideas on revising the API.
Below are some possible changes presented in a few cases. But whatever we do, we should strive for a coherent API.
Import
We could use the builder pattern even more systematically like this:
Note the change from
Import.init
toImport.config
, which is more descriptive.Importing a list of unqualified modules can be done via
One could add to this the construct
Implementation notes
FieldInTypeAlias
Suppose we change the implementation of our
makeRule
toso that the last argument of
makeRule
is a list. We could, of course, always sayto do what we already do with a slight change of syntax.
TypeVariant
Following the suggestions of
FieldInTypeAlias
and the goal of a coherent API, we could replace the list of rulesby the single rule
Initializer
Likewise, the list of rules
could be replaced by the single rule
Notes
The cumulative effect of these changes would be quite large, .e.g., on the monstrous rule set for magic link authentication. A rough estimate: a reduction from 92 to 11 rules (if we also do something similar for
ClauseInCase
)The text was updated successfully, but these errors were encountered: