I've made substantial enhancements to gen-class over the weekend. Please refresh and read:
http://clojure.org/compilation In short, I've made it so that you can call gen-class stand-alone. This will generate a stub class at AOT compile time. The relationship between a generated class and its implementing namespace is now parameterized, as is whether or not the implementing ns gets loaded by the class, and the prefix used by the method->var mapping. You can still use :gen-class in a ns directive, and many parameters will be defaulted. (:gen-class) by itself will give you a class with the same name as the ns, a main function, and "-" as the prefix. Note that now, without any (:gen-class) in ns, you will _not_ get a stub class generated. This brings tremendous flexibility - you can define macros that expand into gen-class calls, and both declare and implement multiple classes in a single file. I've also added gen-interface, based on a contribution from Chouser, which works similarly at AOT compile time. I've enhanced proxy so that it, too, will pre-generate the proxy classes at AOT compile time, although doing so is not necessary in order to use proxy. The interface of the proxy API is unchanged. Two advantages come from this: Proxies now have deterministic names, and so their construction can be a direct constructor call, rather than reflective, as it was previously. Proxy generation was the last runtime code-gen/classloader requirement. So the path is clear for building Clojure apps without runtime codegen, for delivery in those environments that preclude it (e.g. Android, unsigned applets). Looking forward to feedback from people trying to reach those targets. Rich On Nov 27, 10:32 am, Rich Hickey <[EMAIL PROTECTED]> wrote: > On Nov 26, 11:06 pm, Chas Emerick <[EMAIL PROTECTED]> wrote: > > > > > Looks good so far, Rich. Should be a blissfully smooth transition > > from the "legacy" gen-class impl. > > > This is only tangentially related to the docs you're writing, but I > > won't let that stop me: > > > As you know, I have at least one use case where being able to generate > > gen-class specs from a macro (or, the full ns declaration, in the > > absence of an evaluated gen-class spec). Going one step further than > > that though, I'm wondering how best to approach contexts where one > > would like to generate classes whose names don't match up with the > > name of the current file (or with the package the generated class will > > land from the current file). Right off the top of my head, easily and > > cleanly generating BeanInfo classes based on attributes/methods/ > > interfaces/whatever of the current file's class would be super-handy. > > > This doesn't look possible right now -- adding a second, different ns > > declaration does not generate the corresponding classfiles. The docs > > you've written so far make it sound like this should work -- "The unit > > of compilation is the namespace" -- but right now, it seems like files > > are the unit of compilation. Just as an example, assume the following > > is in com/foo/test.clj: > > > (ns com.foo.test > > (:gen-class > > :implements [java.util.Iterator] > > :init ctor > > :constructors {[String] []} > > :state state)) > > > (ns com.foo.test2 > > (:gen-class > > :implements [java.util.Iterator] > > :init ctor > > :constructors {[String] []} > > :state state)) > > --------- > > > (compile 'com.foo.test) yields the com.foo.test classfiles one would > > expect. However, (compile 'com.foo.test2) throws an exception, as > > it's looking for a com/foo/test2.clj file (rather than using whatever > > has already been defined in the com.foo.test2 namespace). I see why > > that's the case, as compilation and loading are very tightly bound. > > If that's going to remain the case, then I'd say that clj files are > > the unit of compilation, not namespaces. It's not yet clear (to me, > > anyway) whether the current state is an intermediate stable step, or > > if the first cut on the docs are slightly off on this point. > > > - Chas > > The unit of compilation will probably be called the 'lib', but that > isn't defined anywhere on the site yet. As far as 2 or more ns calls > in the same file, that violates the ns/file classpath requirements, > which say that my.ns.lib must be defined in my/ns/lib.clj. I'll make > the requirement that ns be the first expression in any file that > contains it explicit. > > That doesn't make the unit of compilation the file though, as a > namespace can be defined in more than one file. > > All that notwithstanding, I understand your needs and those of the few > others who have chimed in that were using gen-and-save-class, and I > hope to facilitate most of them soon. > > One thing I have been considering is the possibility to opt-out of > generating a class when compiling (ns ...) via something like (ns > (:gen-class :external true) ...), which would state that the class > signature was going to be defined in a subsequent stand-alone gen- > class call. That way you could generate such calls via custom macros. > > gen-class will always create a relationship between the stub class and > the load (__init) class, as well as the namespace in which the > implementations will be found, the naming conventions for matching > etc. It's a high-level feature with a lot of power, but by no means > represents a universal solution for all possible code generation > scenarios. I think there will be other applications of programmatic > class generation that will fall out of its scope, and people are free > to build whatever they want - if things prove generally useful they > can propose for core. Everyone can leverage the fact that ASM is built > in, and use gen-class as an example. > > 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
