On Oct 19, 1:12 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> At that point, I'll have some syntax for adorning defns with metadata
> that will do what was once the work of genclass, and I'll be able to
> incorporate in that the enhancements to genclass that have been
> requested.
>
> I hope to have some drops of AOT soon after I return from Lisp50 at
> OOPSLA. Until then, I'd encourage everyone who has ideas about how the
> metadata annotations might look to chime in.
I'd think you'd annotate each "arity clause" in a fn with it's
destination, and use the function metadata for whole-class things.
(defn Clazz
"example class defined through Clojure"
{:extends OtherClazz
:fields '[#^Integer aaa #^Integer bbb]}
;; super constructor args specified
#^{:constructor [Object Object]}
([this #^Integer init-aaa]
(prn "initializing")
;; vector returned for super constructor args
[4 5])
;; a simple method that returns the sum of an argument and a field
#^{:method fff}
(#^BigInteger [this n]
(+ (. this aaa) n)))
(I haven't played with metadata enough so some details may be
off)
I left out the initialization of the fields as they either have to be
returned from our "constructor" as a map (like what gen-class does),
or they have to be non-final so they can be set from our external
"constructor", or the complete constructor has to be baked into the
class making it completely non-malleable. The function compilation
code needs to know about every possible detail we wish to support. I'd
hope it would be possible to define static members, mutable fields,
annotations, etc, so that generated classes could look like first-
class JVM libraries rather than wrappers. (A Clojure library would
likely expose functional semantics over setField methods, but I don't
see a reason to disallow mutable fields. But does code to generate
mutable fields belong in the core?)
What could be a lot simpler and more flexible is providing a hook into
the compiler that would take a method expression (one function arity
clause) and an ASM MethodVisitor on which to write bytecode. With some
primitive forms for calling super methods/constructors and hooks into
AOT class saving, Clojure macros could be written to generate any sort
of class, while all of the details and tradeoffs could be kept well
away from Compiler land. (One could even extend those macros to
generate some hand-assembled methods if they needed more exact control
and didn't want to drop to Java)
Steve
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
