On Fri, Nov 20, 2009 at 2:28 PM, Richard Newman <holyg...@gmail.com> wrote:
> > But I should be able to know, through class inspection, whether my > > 'main' program depends on a class which uses, say, the clojure.zip > > namespace, and decide whether or not to include it. Or so I am > > wondering. > > There are impediments to that, too -- your namespace might require > another, and so on, and your namespace can refer to symbols further > down the chain without itself including the necessary `require` form. > There's the possibility of a macro expanding to a nonobvious require or use form. Also of "eval" being used. Even in the Java world, class names that get dynamically loaded sometimes come from XML files rather than being in the Java source anywhere. But there is an alternative to static analysis, at least in theory. One could, in principle, run one's new app or servlet or whatever on a JVM with a modified class-loading infrastructure set up to log all loaded classes, then put it through its paces in typical usage scenarios and the anticipated atypical situations. If you have good test coverage, you could simply run the test suite with class-loading logging enabled, and make any appropriate substitutions of real classes (and their dependencies) for mock-object classes. Or if the tests don't use any mock objects in really obscure cases whose real counterparts aren't also used in the typical situation, just log a normal run and a run through the test suite and dump all the mock object classes and test-harness classes. Sun probably provides debug tools that can log classes loaded on a JVM session, so everything needed for this is in theory available off-the-shelf. End product: a list of every used class. At least in theory. -- 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
