On Dec 21, 1:50 pm, Charles Oliver Nutter <[email protected]> wrote: > On Mon, Dec 21, 2009 at 6:43 AM, Rich Hickey <[email protected]> wrote: > > Generating .class files isn't necessarily 'overkill'. I agree with > > Per, this is a standard representation. Given such .class files in the > > classpath, all of our existing compilers and tools will 'just work', > > right now. Reflection will work, etc. > > I'm not sure where reflection comes into this, unless you're referring > to one way the top-level compiler stuff would get class data (and > reflection may be a particularly poor way, since it has to *load* the > classes and requires that they be valid/complete to do so, rather than > just reading the data format). Generally we're talking about .class > data and Java-centric type structures across languages. What do you > need reflection for at compile time? >
You are missing the point. .class file *are* a data format. And everything in the Java ecosystem understands them already. APIs *are not* a data format, they are a means for live communication between program entities. > > In Clojure, when in such a situation, I generate stub classes in > > memory, just as Per describes, and for the same reason, everything > > downstream just works. > > Sure, I'm sure the generating dumb stubs can work, but it essentially > means having to do almost the entire compile process twice for every > language: > Dumb stubs vs smart stubs? That doesn't follow. We will have to do precisely and just as much work as is necessary to determine our types and method signatures, then generate something (either a stub .class file, *or* an instance of something implementing these javax interfaces, which in turn need more instances of other interfaces, essentially forcing each of us to duplicate the reflection API, ugh, why?) > * All languages generate stubs into a common location (possibly > in-memory and combined with classpath) > * All languages generate final code based on that common location > > And we *still* need a coordinator since we all have different ways to > generate stubs or trigger a final compilation. > Yes. But with Per's suggestion, that process is significantly more decoupled, and allows for more reuse of existing capabilities. > I don't really care much about the data format. Stub .class files are > essentially just a richer and less flexible version of the > mirror/javax.lang stuff, but certainly contain all the data we need > (and potentially a lot of data we don't need...or can't generate > without a full compile?) Really, I don't know what you are talking about. Generating a class file is a simple thing for all of us to do, and we already do it. A 'stub' classfile doesn't need anything other than fabricated returns. There is no "potentially a lot of..." And again, javax.lang is not a data format. > so they'd probably be fine for a simple first > pass. But are you saying that having a common compiler infrastructure > that actually speaks mirror interfaces rather than .class data > *wouldn't* be good to have? > I'm saying it would be premature to dismiss Per's suggestion with hyperbole about *dumb* stubs and "a lot of xxx we don't need". There is tremendous value in: an actual data format that everyone already consumes and everyone already produces Being able to point a tool at some .class files and get a javax.lang model would be great, but that should be a single job (if not done already) we all could leverage, vs each of us having to implement javax.lang interfaces, and programmatic access to same, directly. Rich -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
