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 n
> 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 with
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 over-engine
> 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.
Th
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 Gardn
