@alexander-yakushev pointed out that using ns as a generic module/namespace key in eval and completions "reeks Clojure" and undermines the language-agnostic framing of the protocol. @technomancy agreed that a more neutral name would fit better if starting from scratch, but asked whether it's worth breaking compatibility. @alexander-yakushev replied no.
Effectively settled as "keep ns for compatibility", but the spec should say that explicitly so future readers don't read the choice as a recommendation.
My take:
- I'm fine with keeping
ns as is. Perhaps down the road we can add a more generic property (namespace, module, etc.) as an alias for it.
- In general I think whatever we pick initially should be fairly close to what we currently have in the wild and build on top of it (as that'd be the least painful path).
@alexander-yakushev pointed out that using
nsas a generic module/namespace key inevalandcompletions"reeks Clojure" and undermines the language-agnostic framing of the protocol. @technomancy agreed that a more neutral name would fit better if starting from scratch, but asked whether it's worth breaking compatibility. @alexander-yakushev replied no.Effectively settled as "keep
nsfor compatibility", but the spec should say that explicitly so future readers don't read the choice as a recommendation.My take:
nsas is. Perhaps down the road we can add a more generic property (namespace,module, etc.) as an alias for it.