[853] in java-interest
Re:mutual dependencies among public classes
daemon@ATHENA.MIT.EDU (David Gunn)
Fri Aug 11 15:16:57 1995
Date: Fri, 11 Aug 1995 13:23:44 +0100
To: java-interest@java.sun.com
From: econsoft@wintermute.co.uk (David Gunn)
I haven't seen any response to Doug Leas message, and it is so fundamental to
my needs that I thought I would repeat it and emphasise how important it is.
>From: Doug Lea <dl@altair.cs.oswego.edu>
>Date: Fri, 4 Aug 1995 13:04:30 -0400
>Subject: mutual dependencies among public classes
>
>If two classes cyclically reference each other, then it appears that
>they must be defined in the same source file. While I can't find
>anything in the spec saying so, it seems that all symbols
>encountered must be resolvable within the same compilation unit (file)
>and/or its imported classes. So if two classes reference each other,
>this can only happen if they are defined in the same file.
Maybe declarations should be allowed for classes which are in a different
source file.
These declarations would be used as a last resort by the compiler if the
compiled file cannot be found, emitting a warning message in that case.
>On the other hand, the Java spec (section 1) says
>
> Although each Java compilation unit can contain multiple classes or
> interfaces, at most one class or interface per compilation unit can be
> public.
>
>Luckily, this rule does not seem to be enforced in the current
>(alpha3) compiler. Otherwise there would be no way to declare pairs of
>mutually referential public classes. It's not all that rare to want
>to define such classes.
It certainly ain't. I'm writing an Economic Simulation Framework. Mutually
referential
classes are crucual to this. Producers and customers must know eachothers
identities otherwise the introduced inflexibility makes the system fragile,
witness the Soviet Union.
I would think this applies to any decentralised system where the entities
'think' and
'communicate' such as many artificial intelligence systems.
This kind of system is a major growth area, because it is non-fragile and
efficient in developer co-ordination and sometimes even runtime efficient.
The mutually referential classes have to be allowed to be in seperate files
though.
If multiple interfaces per compilation unit continues to be allowed, I would
suggest
that the classes in the same file can automaticly regard eachother as
'friends' and
hence access eachothers private data.
>
>Questions:
>
> Is the section 1 rule wrongly stated?
>
> If not, is there a different, supported way to define mutually
> referential public classes?
>
> If so, can the compiler be changed so as not to issue these
> warning messages?
>
>- --
>Doug Lea | dl@cs.oswego.edu | dl@cat.syr.edu | 315-341-2688 | FAX 315-341-5424
>Computer Science Dept, SUNY Oswego, Oswego, NY 13126 | http://g.oswego.edu/dl/
>Also: Software Eng. Lab, NY CASE Center, Syracuse Univ, Syracuse NY 13244
>
David.Gunn@econsoft.wintermute.co.uk
"All opinions must be my own since nobody
pays me enough to be their mouthpiece."
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
