From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,aea4cc77526f5e4a X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Separate Compilation in Programming Languages Date: Mon, 25 Feb 2008 08:12:26 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <7xJvj.7420$Ru4.4246@newssvr19.news.prodigy.net> <5b9wj.4639$Mh2.1432@nlpi069.nbdc.sbc.com> <5Ekwj.10401$0o7.6822@newssvr13.news.prodigy.net> <%Ntwj.12620$Ch6.11402@newssvr11.news.prodigy.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1203945148 9701 192.74.137.71 (25 Feb 2008 13:12:28 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 25 Feb 2008 13:12:28 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:Bj8XbWuZbGKA9P93hDU2YALZOII= Xref: g2news1.google.com comp.lang.ada:20051 Date: 2008-02-25T08:12:26-05:00 List-Id: writes: > Perhaps. But I still don't see how one can defer the dependency of a > Java signature to the implementation of the Java class and prevent > the need for recompiling the entire architecture when the signature of > a parent class changes. The ripple effect through the entire chain > of dependencies when one of those signatures changes is almost > certain to be affected by such a change of signature. I think perhaps what you are missing is that in Java, you can use the same "trick" all along the chain. (The "trick" illustrated by the examples I showed.) E.g., in Ada, you are advocating something like this: E spec (no with's) E body (says "with D") D spec (no with's) D body (says "with C") C spec (no with's) C body (says "with B") B spec (no with's) B body (says "with A") A spec (no with's) A body (no with's) ...to the extent possible, pushing with's into bodies. So if, say, B spec changes, you need to recompile B body and C body, but not (down the chain) D or E. Here, we have 10 source files. The analogous thing with interfaces is: E interface (no with's) E.Implementation (says "with D") D interface (no with's) D.Implementation (says "with C") C interface (no with's) C.Implementation (says "with B") B interface (no with's) B.Implementation (says "with A") A interface (no with's) A.Implementation (no with's) In Ada, each "implementation" is a spec and a body, whereas in Java it's just one class file -- but that's irrelevant. In Ada, we have 15 source files (5 of which are empty or nearly so), but in Java, only 10, as in the previous Ada case. If you change B interface, you have to recompile B.Implementation (spec and body) and C.Implementation (spec and body), but not anything down the chain (D/E). Note that in this method, there are no dependences on the Implementation packages, or very few. Clients such as C.Implementation do NOT say "with B.Implementation"! (I'm ignoring private parts and generics, which throw a monkey wrench into the works.) >...If Java can > somehow accomodate that change automatically, ... Ah, maybe that's the problem. No, it's not automatic. In Java, you have to choose to split out all those interfaces, all down the chain. And you have to take care to make every implementation class depend on interfaces, rather than other implementations. A simpler structure is: E (says "with D") D (says "with C") C (says "with B") B (says "with A") A (no with's) (except Java doesn't call it "with"). In this simpler structure, you do indeed have the ripple effect you're worried about. >...it must be some > kind of magic that is not immediately apparent, even to the Java > developers I know. It's not magic! It requires effort. It is perhaps easier in Ada. But I think the "trick" (or "technique") is well known among Java programmers. - Bob