2009/10/15 Manuel Woelker <manuel.woel...@gmail.com>
>
> On Thu, Oct 15, 2009 at 9:43 PM, Laurent PETIT <laurent.pe...@gmail.com>
> wrote:
> > 2009/10/15 Manuel Woelker <manuel.woel...@gmail.com>
> >>
> >> On Thu, Oct 15, 2009 at 5:48 AM, jng27 <jgran...@gmail.com> wrote:
> >> >
> >> > The following seems like it could be a common scenario when attempting
> >> > to re-write parts of an existing Java application in Clojure.
> >> >
> >> > Let's say there exists Clojure code and Java code in the same
> >> > 'project'.
> >> > The Clojure code depends on the Java code in one direction and then
> >> > the same is true in the opposite direction.
> >> > Given that compiling Java and Clojure require separate and different
> >> > compilation steps, how would circular dependencies be resolved ?
> >> > e.g. A class is defined in the Clojure code that references Java
> >> > classes(yet to be compiled) and the same is true for the Java code
> >> > referencing classes defined in Clojure(yet to be compiled). It doesn't
> >> > seem like compiling one before the other would solve this issue.
> >> >
> >> One possible solution that could be feasible is a two pass compilation
> >> for clojure. The first compilation pass would basically just generate
> >> the skeletons for the classes, i.e. just the method "heads" with each
> >> method body being ignored and replaced with 'throw new
> >> IllegalStateExccpetion("You are using first pass compilation
> >> results")' or something along those lines. After this compilation pass
> >> the Java classes can be compiled just fine, since all method calls can
> >> be resolved. Finally the second pass of the clojure compilation fills
> >> in the real method bodies, now that Java classes have been generated.
> >> This should in theory work for most scenarios.
> >
> > But there is still the case of true circular dependencies between
> > definitions, even of interfaces (let's not talk about implementation
> code) :
> >
> > A java interface JavaInterface with a method of signature
> "ClojureInterface
> > foo()"
> > A clojure generated interface (via gen-interface) ClojureInterface with a
> > method of signature "JavaInterface bar()"
> >
> > Compiling JavaInterface requires ClojureInterface
> > Compiling ClojureInterface requires JavaInterface
> >
> > chess mat if not done by the same ubiquitous compiler :-(
> >
> I don't think so. The clojure compiler sees the method "JavaInterface
> bar()". In the first pass, it just assumes the JavaInterface to exist
> (i.e. that there is at least an "interface JavaInterface {}"
> somewhere). In this pass we do not care what the interface actually
> looks like, so we don't need it's definiton. We can thus produce
> stubbed "ClojureInterface.class". On the second pass, we expect the
> Java compiler to have compile the JavaInterface (which it can because
> it finds the ClojureInterface). Now we perform the usual checks,
> resolve JavaInterface see that it exists and do the normal compilation
> yielding the actual "ClojureInterface.class" with meaningful method
> bodies, and all is well.
>
> It seems that internally the java compilers (which are faced with the
> same problem in similar situation) follow a similar strategy. Of
> course they can forego the luxury of generating stubbed class files,
> and keep the state in their symbol table.
> (c.f.
> http://openjdk.java.net/groups/compiler/doc/compilation-overview/index.html
> though a little light on details)
>
>
If you're right, that's pretty cool ! (and I'm not at all versed into this
kind of stuff, so I really hope you're right and my feelings were wrong ! :)
--~--~---------~--~----~------------~-------~--~----~
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
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
