On Mon, Dec 21, 2009 at 3:24 PM, Rich Hickey <[email protected]> wrote:
> 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 I agree. Because my compiler is not (yet) self-hosting, I use "javap -public" to get what I need out of .class files, so I definitely want an offline way of getting information about classes I don't generate. In any case, the issue of how to consume a remote class is not trivial. I know how to consume Java classes and expose them, but classes compiled by a non-Java compiler may have invocation and use patterns that I don't know. This is especially true in "foo module = Java class" compilation strategies, including my own -- a random JVM programming language wouldn't know what to do (more importantly, what not to do) with one of my .class files. > > 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. > > > -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures -- 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.
