Re: Keyword namespacing best practices
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 not, then namespaced keywords
become more tempting to me, so long as the namespace can be aliased for
brevity:
(api/fetch url {:timeout 10})
=> #::api{:status 200, :body ""}
On Mon, 1 Oct 2018 at 02:45, Michael Gardner wrote:
> 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 in the function call? Why or why not?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
James Reeves
booleanknot.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Keyword namespacing best practices
> 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 without breaking clients (or when you control all the clients). But public APIs seem like the place to be forward-thinking, at least for potential breaking changes such as switching to namespaced keywords. > 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-engineer the API > in advance. W.r.t. "over-engineer", tongue-in-cheek: https://www.youtube.com/watch?v=XewVicFzRxw=2m44s -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Keyword namespacing best practices
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-engineer the API in advance. Alan PS: YAGNI rules - and it's easier/less painful to fix the 5% where it's wrong than the 95% where it's right PPS: YMMV (but not much!) On Sun, Sep 30, 2018 at 7:12 PM Michael Gardner wrote: > > > 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. > > Thanks for the response, Eric. Leaving :timeout aside for the moment, the > issue I'm wrestling with is that you never know what your clients will do > with the response. That makes it hard to anticipate the likelihood of > keyword collisions, especially for a more complex compound response. There > are also some fringe benefits, like greater synergy with clojure.spec and a > kind of self-description effect (again, more relevant for larger APIs). > > I've also heard some library developers say they've adopted namespaced > keywords almost everywhere, so I guess I'm just wondering about where to > draw that line. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Keyword namespacing best practices
> 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. Thanks for the response, Eric. Leaving :timeout aside for the moment, the issue I'm wrestling with is that you never know what your clients will do with the response. That makes it hard to anticipate the likelihood of keyword collisions, especially for a more complex compound response. There are also some fringe benefits, like greater synergy with clojure.spec and a kind of self-description effect (again, more relevant for larger APIs). I've also heard some library developers say they've adopted namespaced keywords almost everywhere, so I guess I'm just wondering about where to draw that line. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Keyword namespacing best practices
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 Gardner wrote:
>
> 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 in the function call? Why or why not?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Keyword namespacing best practices
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 in the function call? Why or why not?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
