At 02:45 AM 12/1/98 -0800, Mark S. Miller wrote:
>At 02:10 AM 12/1/98 , Ka-Ping Yee wrote:
>>[#] Cyclic dependencies should be fine within a package. But
>>even the problem with cyclic dependencies between packages seems
>>suspect. It doesn't make sense that guavac should expect you to
>>compile all the dependents in exactly the right order -- it should
>>be able to figure that out (as jikes does, admirably).
>
>[+] I hadn't meant to imply that guavac isn't broken.
>We'd have to look at the Java Language Specification to be sure, but I
>believe a Java compiler must be able to eat a source tree with
>inter-package cyclic dependencies. However, it's good for systems to be
>layered, as they can be understood in an order. (The book "Large Scale
>Programming in C++", which Bill & Dean are big fans of, states many reasons
>to avoid cycles. Bill? Dean?) E is currently far from this ideal.
[#]There are a large number of reasons:
In the case of E, I think we are up against a fundamental difference between Java's and make's philosophy.
In C/C++ the interface is defined by the .h file. That file is generated independently from the compiler, so when you follow the tradition of having a makefile in every subdirectory, those make files can refer to the interface of components that have not yet been built.
In Java, the interface is defined by the .class file and generated by the compiler. If you haven't generated the .class file, then the interface is unavailable. In order to compile packages which are circularly dependent, you have to present all of them to the same compiler invocation. This requirement is in direct conflict with the convention of a makefile in each directory.
The best way to avoid this conundrum is to avoid the circular dependencies. "Large Scale C++ Software Design" by John Lakos (Addison-Wesley) is largely devoted to ways of accomplishing this goal.