[1111] in java-interest
Re: mutually dependent public classes
daemon@ATHENA.MIT.EDU (Mick Jordan)
Fri Aug 18 23:17:34 1995
Date: Fri, 18 Aug 1995 17:26:44 -0700
From: Mick.Jordan@Eng.Sun.COM (Mick Jordan)
To: java-interest@java.Eng.Sun.COM
> I don't think this issue has been completely cleared. Once again, the
> problem is what if two classes both need to know about each other.
> For example consider two public classes A and B. Neither file can be
> compiled because the other .class file doesnt' exist yet.
>
> Someone suggested using interfaces. Is this the only solution?
>
Cycles in "interfaces" (compilation units in this case) are often
outlawed in modular languages (e.g. Modula-3) because they effectively
require that all the units in the cycle are compiled simultaneously.
Various tricks are employed to circumvent the problem, e.g. opaque
types in Modula-3, "class Foo;" in C++, "interface" in Java. Things are
pretty hopeless if the compilation environment is built in such a way
that the compiler depends on the existence of "compiled units", e.g.
".class" files. Ideally the compiler should be prepared to work with
source, and treat ".class" files as an optimization. That removes
problems of partial ordering, but it takes more work to cope with
arbitrary cycles. It gets worse if you want to permit cycles between
widely separated parts of a large system (arguably a bad design) since,
in the limit, you have to compile the entire system in one go.
Hopefully this issue will get resolved (in an implementation independent
manner) by the 1.0 language definition.
Mick Jordan
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
