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!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr13.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: <7xJvj.7420$Ru4.4246@newssvr19.news.prodigy.net> <5b9wj.4639$Mh2.1432@nlpi069.nbdc.sbc.com> Subject: Re: Separate Compilation in Programming Languages X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-ID: <5Ekwj.10401$0o7.6822@newssvr13.news.prodigy.net> NNTP-Posting-Host: 70.134.112.39 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr13.news.prodigy.net 1203885697 ST000 70.134.112.39 (Sun, 24 Feb 2008 15:41:37 EST) NNTP-Posting-Date: Sun, 24 Feb 2008 15:41:37 EST Organization: SBC http://yahoo.sbc.com X-UserInfo1: O@Y[R^[GZRRER_H]]RKB_UDAZZ\DPCPDLXUNNHLHEQR@ETUCCNSKQFCY@TXDX_WHSVB]ZEJLSNY\^J[CUVSA_QLFC^RQHUPH[P[NRWCCMLSNPOD_ESALHUK@TDFUZHBLJ\XGKL^NXA\EVHSP[D_C^B_^JCX^W]CHBAX]POG@SSAZQ\LE[DCNMUPG_VSC@VJM Date: Sun, 24 Feb 2008 20:41:37 GMT Xref: g2news1.google.com comp.lang.ada:20044 Date: 2008-02-24T20:41:37+00:00 List-Id: "Ray Blaak" wrote in message news:ulk5a8zcu.fsf@STRIPCAPStelus.net... > writes: >> When the dependencies are deferred to the implementation module (an Ada >> package body) a change to a parent specification requires only that body to >> be recompiled. When the specification is at the level of another >> specification, and a change is made to a higher level unit, everything needs >> to be recompiled. > > No, not necessarily. It is quite possible that the only an implementation was > client of the changed spec, and that the change's effects do not perculate > out. That is, the change is not transitive. > Absolutely true, and confirmation of my original point. We want to defer dependencies to the implementation whenever possible so those changes do not "percolate" throughout the rest of the architecture. >> I think this is as true of Java as it is of Ada. The only difference is >> that Ada allows one to defer the dependency to the package body. This does >> not seem to be true of Java. > Agree. It certainly does not seem to be true of Java. > The deferral to a package body is precisely equivalent to the deferral to > another implementation class. The implementation class is (or can be) private, > hidden in exactly the same way the body of a package is. > > That is what allows Java interfaces to serve as equivalent controls for > separate compilation as Ada's package bodies. Mind you, they're not > necessarily as convenient, mind you, but I am objecting only to the notion > that Java does not support separate compilation. > Java's notion of separate compilation is not evil. However, it does fall short of what can be done in Ada. Interfaces, while such a good idea in Java that they have been adopted by Ada, do not solve the dependency issue and do not provide the capabilities for architectural integrity possible in Ada. An implementation of an Interface (in Java) is still tightly bound to its specification, and any change of that implementation will carry forward. It is true that the Interface specification remains unchanged, and that is a good thing. However, if any part of the Interface specification changes, every other unit dependent on that specification will also have to be recompiled. In the Ada model, where I defer the dependency on that Interface to the body of the dependent package, I need not recompile the specification of the dependent package. Rather, I can compile only the body, leaving the rest of my architecture intact. I'm not sure why this is such a difficult idea. It is probably because I am not expressing it with sufficient skill. Richard Riehle