On 12/21/2009 12:54 PM, Charles Oliver Nutter wrote:
> If your claim is that we can just have all languages generate stub
> classes, point all languages at the stub classes, and have them
> regenerate real classes...then I think you're wrong. James Iry's case
> of type inference in Scala shows that much, since the return type of a
> given method (which you would need to put in the stub) depends on the
> return value of some other method (which may not be available at
> stub-generation time or which may have circular dependencies).
If the return type of an exported method depends on type inference
and that inference may have circular cross-module dependencies,
my reaction is: Don't do that. You can't define a stable API
that way, at least not a library API. It might be OK for a
module-private method (in the sense of JSR-294 - i.e. a group of
classes that go together), but the use-case where you might
need to infer return types across language boundaries seems
pretty low-priority.
> Stubs work great if everyone knows (at least symbolically) what types
> all their Java-facing types will return and receive, and can determine
> that based on existing on-disk or in-memory data. That's obvious, and
> that's how, for example, the Groovy joint compiler works (since it and
> Java do not infer return types in the way that Scala does). Is that
> all we want?
It may be good enough - or at least a good start.
> And if .class files are enough, I will happily concede that they're
> the best approach for the problem. Like I said...I don't care!
> Ultimately a joint compiler that knows how to work with all those
> .class files (or with a mirror API to language-specific data) and
> trigger a subsequent "complete" compile still needs to be there, which
> is the point of this thread.
And I'll happily concede using a standard API might work better.
A key issue is how easy it is to fit javac into the framework.
In theory we have the option of adding functionality to OpenJDK,
but of course we really want something that can work with Java 6
(or even Java 5, though that's lower priority).
--
--Per Bothner
[email protected] http://per.bothner.com/
--
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.
