> 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. >
Let me see if I follow the plan for gen-class: By and large, most common cases will be handled with the :gen-class option of (ns ...). For those that need to generate classes in a more flexible manner, the more primitive gen-class function (as opposed to gen-and-load-class or gen-and-save-class) will still be exposed to users who need/want to make use of that? e.g. Chas' idea for generating BeanInfo classes would fall under a call to gen-class, which has no constraints on the name of the class generated in relation to the namespace. And on top of that, the ASM lib is built into the distribution so anyone who wants to generate fully customized bytecode can do so. Do I have that right? /mike. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
