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
-~----------~----~----~----~------~----~------~--~---
