Welcome! Please see the About page for a little more info on how this works.

+17 votes
in Namespaces and vars by

It is useful to make qualified keywords, and particularly so with spec. Using namespace aliases helps a lot in working with a lot of qualified keywords. However, currently creating an aliased namespace requires that the namespace actually exists.

This ticket is a placeholder to do something more with lighter-weight aliasing for keywords. Details TBD.

8 Answers

0 votes
by

Comment made by: bendlas

Hoping to get the conversation started on this in time for a 1.9-beta:

The rationale in my predecessor ticket, CLJ-2030, was to create a construct to allow for auto-aliasing in .cljc files, which I would like to submit as a requirement. The obvious place for cljs to declare an auto-alias is the ns clause.
So if we don't want to grow alias for that use case, I would propose to grow the ns clause with a declaration for keyword - aliases. Let's give it a working title of (:kwns-alias ..) for this comment.

:kwns-alias would be used to establish namespace aliases for ::qualified/keywords

One open question is, how :kwns-alias should interact with alias. i.e. whether the namespace of ::qualified/keyword should always expand to the same as the one of a qualified/symbol or if they should be allowed to differ. I'd argue they should always be the same, because of the rule of simplicity. That means, that
- alias will need to check if the sym is already in :kwns-alias and throw, if so
- :kwns-alias will need to also work on `qualified/keywords probably shouldn't have knws in its name any more

So what's a good name for :kwns-alias? :let maybe?

0 votes
by

Comment made by: alexmiller

beta = feature complete, so this isn't happening in 1.9.

I think adding anything to ns is likely off the table, but until I learn more about what Rich has in mind, I can't really suggest anything more.

0 votes
by

Comment made by: bendlas

that's a pity. but maybe 1.10 will have a shorter release time ...

In any case, I'll be very interested in Rich's idea to do this outside of the ns clause and still have it fit well with clojurescript (or even clojure, for that matter, ...)
Do you have any rationale, why growing ns for this is a bad idea?

0 votes
by

Comment made by: alexmiller

ns already does way too much stuff and we don't have any desire to make it do more.

0 votes
by

Comment made by: bendlas

Since ns is essential to how a namespace is set up in clojure, I'd imagine a fix for that problem (of ns doing too much) to imply some rather drastic changes to the state of the art. As we won't break ns, I'd imagine either some sort of ns2 or a way to do namespace setup outside of the ns clause. I'm curious either way.

Since I know, that Rich will not be hassled about his hammock time, I'll lay off this for now. I'll be sure to check back as the next round of alphas goes out. I also hope for some productive discussion in the meantime.

0 votes
by

Comment made by: tslocke

Is there any reason such a mechanism would be limited to keywords? I have a place in my code where it would be very useful to have such a feature for symbols.

Also, related: a way for pr-str (and similar) to be configured to use short versions of namespaces. Debug output can be awfully noisy, even with namespaced maps.

0 votes
by

Comment made by: alexmiller

No particular reason - usually for stuff like this we make it work the same for any ident (keyword or symbol).

0 votes
by
Reference: https://clojure.atlassian.net/browse/CLJ-2123 (reported by alexmiller)
...