I'd prefer an option map over kwargs in general, and I wouldn't namespace
the options because they're not something that I'd expect to stick around.
(fetch url {:timeout 10})
Regarding the output, if it's a Ring response map, I'd be inclined to leave
the keywords bare for compatibility. If it's
> On Sep 30, 2018, at 23:41, Alan Thompson wrote:
>
> It is easy to overdo it when trying to predict future needs. I always (now)
> do the minimal solution, with the expectation that it *may* evolve in the
> future.
Normally I'd agree: YAGNI is great for functionality that can be added
It is easy to overdo it when trying to predict future needs. I always
(now) do the minimal solution, with the expectation that it *may* evolve in
the future.
Since the parts that do need change (say 5% ?) are usually not the ones I
would have predicted, I am usually very glad I didn't
> On Sep 30, 2018, at 18:54, Eric Lavigne wrote:
>
> I would not use keyword namespaces in this situation. Users of the "fetch"
> function will likely type :timeout, :status, and :body when using this
> function. Keyword namespaces would just force users to type longer names for
> these.
I would not use keyword namespaces in this situation. Users of the "fetch"
function will likely type :timeout, :status, and :body when using this
function. Keyword namespaces would just force users to type longer names
for these.
On Sunday, September 30, 2018 at 9:45:56 PM UTC-4, Michael
I'm looking for some feedback on keyword namespacing. Say you're writing an API
to be used by external clients that works something like this:
(fetch url :timeout 10)
=> {:status 200, :body "..."}
Would you namespace the :status and :body keywords in the response? What about
the :timeout kwarg
