Hmm, which maybe is not any kind of solution for your question, since it
uses require, which you as you already mentioned cannot be used from a
utility namespace to your main namespace, or else you would create a
dependency cycle.

Clojure/Java has "alias" that might help in such situations, but
ClojureScript does not.

Andy

On Wed, Oct 10, 2018 at 5:48 PM Andy Fingerhut <andy.finger...@gmail.com>
wrote:

> There may be other techniques that give you better answers here, but
> regarding your real stumbling block issue of namespaces keywords, not that
> both Clojure and ClojureScript let you write namespaced keywords using
> short alias names that you pick, without having to type out the full
> namespace name.  For example:
>
> % clj -Sdeps "{:deps {org.clojure/clojurescript {:mvn/version
> \"1.9.946\"}}}" -m cljs.repl.node
>
> cljs.user=> (require '[clojure.string :as str])
> nil
> cljs.user=> ::str/foo
> :clojure.string/foo
> cljs.user=> (= ::str/foo :clojure.string/foo)
> true
>
>
> Andy
>
> On Wed, Oct 10, 2018 at 2:17 AM Tom Locke <t...@tomlocke.com> wrote:
>
>> I'm working on a library, for which I would like to expose a single
>> namespace to users. I don't want users (including myself!) to have to
>> remember this function comes from foo-lib, this one comes from
>> foo-lib.utils etc.
>>
>> Internally, however, I would very much like to split my code up into
>> separate files. This is not just for convenience (although I do find
>> smaller files much more convenient), but has a material impact on my
>> productivity. A single long file takes a few seconds to compile (usually in
>> figwheel). These pauses really add up and make the overall experience feel
>> sluggish.
>>
>> In Clojure this is a non-issue -- a namespace can be split into multiple
>> files using load and in-ns. We don't have those in ClojureScript.
>>
>> I have tried various approaches to breaking my library up into multiple
>> namespaces, while keeping the single namespace API, but none are
>> satisfactory. I can expose symbols just by def-ing them in the main
>> namespace, e.g. (def foo my-utils/foo). This is inconvenient for editing
>> (e.g. go to definition), but the real stumbling block is namespaced
>> keywords, which I use a lot. As users of the library must use the keywords
>> also, I need them to be in the main namespace. This means my utility
>> namespaces (which cannot require the main namespace due to circular
>> dependencies) would have to use the long-hand keyword syntax (i.e. no :: ).
>> This is too high a price and I am back to everything in a single namespace.
>>
>> Is this issue affecting others? My guess is people just impose multiple
>> namespaces on the consumers of libraries, or are stuck with cumbersome,
>> large namespaces.
>>
>> I came across this old thread, which is related. It didn't get very far:
>> https://groups.google.com/forum/#!topic/clojure/MwGV6GDN9p8
>>
>> Thanks very much
>>
>> Tom
>>
>> P.S. I have seen people mentioning "sub second compiles" in figwheel. I
>> am seeing, e.g. more than 3 seconds to compile a 1,700 file. Does that
>> sound typical? (2012 MacBook Pro)
>>
>> --
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescript@googlegroups.com.
>> Visit this group at https://groups.google.com/group/clojurescript.
>>
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Reply via email to