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!news1.google.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr11.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: <7xJvj.7420$Ru4.4246@newssvr19.news.prodigy.net> <1wkwj.10399$0o7.2971@newssvr13.news.prodigy.net> 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: NNTP-Posting-Host: 70.134.112.39 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr11.news.prodigy.net 1204010995 ST000 70.134.112.39 (Tue, 26 Feb 2008 02:29:55 EST) NNTP-Posting-Date: Tue, 26 Feb 2008 02:29:55 EST Organization: SBC http://yahoo.sbc.com X-UserInfo1: TSU[@I_AOHV[RVT[AROR__TDFZ\@@FXLM@TDOCQDJ@_@FNHB_NVUAH_[BL[\IRKIANGGJBFNJF_DOLSCENSY^U@FRFUEXR@KFXYDBPWBCDQJA@X_DCBHXR[C@\EOKCJLED_SZ@RMWYXYWE_P@\\GOIW^@SYFFSWHFIXMADO@^[ADPRPETLBJ]RDGENSKQQZN Date: Tue, 26 Feb 2008 07:29:55 GMT Xref: g2news1.google.com comp.lang.ada:20078 Date: 2008-02-26T07:29:55+00:00 List-Id: "Robert A Duff" wrote in message news:wccmyppg7yd.fsf@shell01.TheWorld.com... > writes: > >> Yes. I agree. When we defer the implementation to the body, there is >> no need to recompile anything, unless the implementation is tightly >> bound to the specification. The architectural concern is when we >> recompile the specification. Any change to the specification will >> imply a change to everything dependent upon it. > > Right, but in Java, you can always move that dependence into an > implementation of an interface, just like you can move that dependence > down into a package body in Ada. > Even if this completely accurate, the vast majority of Java applications use only a small number of packages that consist of interfaces. The rest of the design does not use the Interface model. For those classes, in those packages, the dependency problem is not only possible but, after doing some additional research today, I find is fairly common. >> In your example, you have deferred the dependency to the body of P2. >> So there is no need to recompile the spec for P2. However, if the with >> clause had been at the specification level of P2, and if the specification >> for P1 had changed, there is certainly a danger of an architectural >> problem if we did not recompile the specification and body for P2. > > Yes, the spec of P2 would need to be recompiled in that case. > I don't see why that's an "architectural problem". > It is an architectural problem because, in Java, a corrupted dependency, something that apparently actually occurs in large-scale Java designs, is also going to corrupt the architecture of the software. As noted in a separate post, this problem has required the introduction of special dependency management tools such as Ivy, Maven, and Ant -- and these tools are not yet able to detect all the problems though they are getting better. Every software entity has an architecture, planned or ad hoc. One of the more important aspects of an architecture is to take every action possible to reduce or manage dependencies between the artifacts of that architecture. The separate compilation model of Ada does that better than most other languages. Modula has some virtues in this respect. However, the research I have been doing on Java leads me to believe that the language has significant weaknesses in architectural stability for large-scale systems. There are quite a few articles on the Internet describing these problems.. > > Right. But the point of my example is that you can always defer the > "with" to an implementation of an interface. > Even if we allow for the benefit of the Interface in this situation, we have not dealt with the larger body of a Java program that is not built using Interfaces. >> In a separate reply, you mentioned generics. In most cases, there is no >> reason why a generic cannot be instantiated at the package body level. > > I don't agree with that. In my experience, when I declare a type T, > I often want a sequence-of-T, or mapping-of-T, or whatever, exposed to > clients, that is done by generic instantiation. > But that does not have to be instantiated at the package spec level. In many cases, the instantiation is possible, and preferred at the body level. Granted, we sometimes have to instantiate at the spec level, but not always. Java templates are usually instantiated at the specification level, and that most certainly introduces a level of dependency with system-wide effects. >> My contention is that the Ada model of dependency management is far >> superior to most other models for the preservation of architectural >> stability. Am I alone in this view? > > I'm not entirely sure what you mean by "architectural stability" here, > but I guess I'd agree if you changed "far superior" to "slightly more > convenient". ;-) > Architectural stability implies that, except under extraordinary circumstances, any change to some artifact of the architecture will have minimal impact on the rest of that architecture. This is one valuable property of Ada's ability to let us defer most of our dependencies to the lowest level of the design possible. This is not a property of Java, C++, or most other languages in current use today. Even incremental compilation falls a little short. Oh, and does Rational Apex still support incremental compilation in Ada? GNAT is not the only Ada environment around. Richard Riehle