Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Variadic keyword arguments don't compose -- provide alternative
Description
The more we work with java.jdbc at World Singles in composition with other functions, the more painful the variadic keyword argument approach becomes, especially as the number of optional keyword arguments grows.
The API would be easier to work with if the optional keyword arguments could be passed as simple maps. This will be straightforward for some functions, by introducing multiple arities, but harder for others. The multiple arity approach should be considered to be a bridge only, as a step toward deprecating the current approach.
As an example, query has the following argument list – and a pretty horrendous arglists specification to try to explain it!
Then the :arglists metadata could be removed (it's non-standard) and the information about sql-params added to the docstring (where it really belongs).
For backward compatibility, an additional arity could be provided:
[db sql-params k v & kvs]
Alex Miller considers this "the worst of all worlds" but I view it purely as a compatibility bridge between the current API (0.5.0) and the cleaner, future API (0.6.0).
Major
The more we work with java.jdbc at World Singles in composition with other functions, the more painful the variadic keyword argument approach becomes, especially as the number of optional keyword arguments grows.
The API would be easier to work with if the optional keyword arguments could be passed as simple maps. This will be straightforward for some functions, by introducing multiple arities, but harder for others. The multiple arity approach should be considered to be a bridge only, as a step toward deprecating the current approach.
As an example,
queryhas the following argument list – and a pretty horrendousarglistsspecification to try to explain it![db sql-params & {:keys [result-set-fn row-fn identifiers as-arrays?] ...}]Instead, it could be:
[db sql-params] [db sql-params {:keys [result-set-fn row-fn identifiers as-arrays?] ...}]Then the
:arglistsmetadata could be removed (it's non-standard) and the information aboutsql-paramsadded to the docstring (where it really belongs).For backward compatibility, an additional arity could be provided:
[db sql-params k v & kvs]Alex Miller considers this "the worst of all worlds" but I view it purely as a compatibility bridge between the current API (0.5.0) and the cleaner, future API (0.6.0).