I remembered bookmarking a library that did something similar, so I
looked at my bookmarks. Here is Zach Tellman's "potemkin" library, you
might be interested in checking it out:
https://github.com/ztellman/potemkin

>From the README :

"Clojure’s namespaces conflate how you implement your code and how
it’s consumed by other code. This isn’t always a bad thing, but in
practice this means that large projects either have surprisingly large
source files (e.g. clojure.core) or a surprising number of namespaces
that have to all be used in concert to accomplish complex tasks (e.g.
Ring).

The former approach places an onus on the creator of the library; the
various orthogonal pieces of his library all coexist, which can make
it difficult to keep everything straight. The latter approach places
an onus on the consumers of the library, forcing them to remember
exactly what functionality resides where before they can actually use
it.

import-fn and import-macro decouple the structure of the code from the
structure of the API, allowing the library creator to structure the
code however he likes, without necessarily requiring that the
consumers have the same intimate understanding of that structure.

As someone who spends a fair amount of time worrying both about the
structure of the code and the presentation of the API, it’s helpful
not to have to think about how one affects the other. You might find
it helpful, too."

/vedang

On Mon, Jan 7, 2013 at 8:12 AM, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Sun, Jan 6, 2013 at 6:17 PM, Stuart Sierra
> <the.stuart.sie...@gmail.com> wrote:
>> 1. `refer`. Define a public function that `refer`s all the symbols you want.
>> It's an extra step for the user, but that's good because it makes it evident
>> that extra symbols are being added.
>
> Forcing all users of a library to refer a whole slew of symbols from
> another library that they don't even know they're using is horrible
> usability and really not a useful suggestion. The user should be able
> to (:require [main-library :refer [what i want]) without being forced
> to know about a transitive dependency and know which symbols come from
> which library, if the main-library developer wishes to provide a
> single, simple API.
>
> Could you explain exactly how this "breaks dynamic binding,
> with-redefs, and the ability to redefine functions at the REPL" given
> the scenario we're discussing? Remember that the whole purpose of this
> discussion is to essentially hide the underlying namespace from which
> symbols originate, and to present a single namespace with the desired
> API.
>
>> 2. `load`. If you have N namespaces with no clashing symbols, then you only
>> need one namespace. If you want to split it across multiple files, use
>> `load`. `clojure.core` does this.
>
> Fine if you control all of the source yourself.
>
> In the case of FW/1, I want a portion of Enlive available directly and
> easily to users of FW/1. Enlive is a transitive dependency - users of
> FW/1 don't need to know about it, and shouldn't really care.
>
> Since this appears to be a relatively common use case for library
> developers, perhaps a native Clojure solution that doesn't have the
> downsides you list would be worth adding? Perhaps some sort of (export
> some-ns/some-symbol) that makes *ns*/some-symbol appear like an exact
> public alias of some-ns/some-symbol? So users of the library see those
> exported symbols exactly as if they were declared in the library
> itself, rather than the third-party dependency, and could interact
> with them as such.
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> 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



-- 
Unix is simple. It takes a genius to understand it's simplicity.    -    Anon
People think it must be fun to be a super genius, but they don't
realize how hard it is to put up with all the idiots in the world.
-    Calvin.

Cheers,
Vedang.

Programmer,
Infinitely Beta.
http://twitter.com/vedang
http://vedang.me

-- 
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

Reply via email to