On Thu, Oct 22, 2009 at 11:11 PM, Alex Osborne <a...@meshy.org> wrote:
>
> > So you could do the same when defining a multimethod, just give the
> > name (symbol) of the method the metadata ":private" with the value
> > "true":
> >
> > (defmulti #{:private true} my-multi my-dispatch)
>
> I'm having a bad day for typos, the example should of course be:
>
> (defmulti #^{:private true} my-multi my-dispatch)
>
I think we need some notion of semi-private as well. It would be ignored by
:use and by automation like tab-completion of symbols, doc generation, and
the like (except it would show in tab-completion inside of its namespace)
but would not actually be illegal to invoke from elsewhere. So, it would be
like private in every respect except for invokability.
The purpose being so that you can make support functions (and perhaps other
things) for macros without cluttering up the publicly-visible symbols list
of the namespace, that is the set exported via :use and :require :as and
affecting tab-completion and documentation generation.
Alternatively, perhaps it would be okay to just get rid of the exception
when a private var is dereferenced outside its namespace? Is it really
important to absolutely bar access to such? Or should private be more about
avoiding clutter in exports, docs, tab-completion, and so forth and about
documenting what's meant to be used as public API, but not really about
access restriction per se?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
