On Mon, Dec 14, 2009 at 1:16 AM, Chouser <chou...@gmail.com> wrote: > On Sun, Dec 13, 2009 at 7:55 PM, Stephen C. Gilardi <squee...@mac.com> wrote: >> >> On Dec 13, 2009, at 6:54 PM, Stuart Halloway wrote: >> >>> That's great. I wouldn't have expected it to work. Do you think this is by >>> design or coincidental/subject to change? >> >> The expression I gave was: >> >> �...@#'clojure.core/spread >> >> equivalent to: >> >> (deref (var clojure.core/spread)) >> >> I see now that the simpler expression: >> >> #'clojure.core/spread >> >> equivalent to >> >> (var clojure.core/spread) >> >> also works: >> >> user=> (#'clojure.core/spread [:a [:b :c]]) >> (:a :b :c) >> >> I think it's by design that privacy is enforced during symbol resolution but >> not during var lookup, var deref, or var invoke. It would be (somewhat) >> complicated and slow for any of the latter 3 to allow using the var from >> within its home namespace but not from within another namespace. >> >> However, I'm not aware of this behavior being explicitly documented so if >> the code relying on it must be future-proof, I recommend checking with Rich. > > I'd like a ruling on this as well. It solves a real problem of > macros getting access to helper functions, so if we shouldn't be > relying on it, a reliable solution would be desirable. > > This technique is actually used in the "new" branch in > core_deftype.clj so that the 'defprotocol' macro can expand into > a usage of a private fn 'assert-same-protocol'. But that doesn't > necessarily prove it's an acceptible solution. >
I'm fine with continuing to allow (var fully.qualified/foo) to work for private vars in other namespaces. That and #'fully.qualified/foo are sufficiently verbose IMO, as the 'private' system is just there to prevent accident, and the leaking of implementation names, not malice. Note that emitting a var in a macro is fine, but please don't emit a dereferenced defn var in a macro (via @) as Steve first showed, as that will actually embed the function object in your code, which is not always possible, nor desirable. Rich -- 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
