Hi, On Oct 23, 8:45 am, Christophe Grand <christo...@cgrand.net> wrote:
> Other solutions are to use @#'ns/private-var to access private vars from the > macro or to make the macro shallow using a public (usually higher-order) > helper function (is this possible in the general case?). It is not 100% possible in the general case but it the vast majority of the cases, I'd say. Concerning the private Vars: I'd actually suggest to dispose them entirely. Namespaces can be split into an interface space contain the public interface. It can 'use' a special internal namespace, which does not belong to the public API of the library. All defs are normal, public defs. This approach solves all problems: - The user knows, what the public API is. - The macros can access everything they need. - Code completion only finds the public stuff. - It doesn't need modifications like a 'semi-private' or 'protected' flag. I think, Stephen exercised this approach in c.c.sql. Sincerely Meikel PS: My opinion: design your library to be used with require and :as instead of use. Document the public API. That is the contract. The contract stays valid whether the system enforces it or 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 -~----------~----~----~----~------~----~------~--~---
