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!news3.google.com!news1.google.com!news.glorb.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!nlpi061.nbdc.sbc.com.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: <7xJvj.7420$Ru4.4246@newssvr19.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.114.51 X-Complaints-To: abuse@prodigy.net X-Trace: nlpi061.nbdc.sbc.com 1203785231 ST000 70.134.114.51 (Sat, 23 Feb 2008 11:47:11 EST) NNTP-Posting-Date: Sat, 23 Feb 2008 11:47:11 EST Organization: AT&T http://yahoo.sbc.com X-UserInfo1: Q[R_PJONTBWQR]TX\ZIBNFXBWR\HPCTL@XT^OBPLAH[\RWYAKVUOPCW[ML\JXUCKVFDYZKBMSFX^OMSAFNTINTDDMVW[X\THOPXZRVOCJTUTPC\_JSBVX\KAOTBAJBVMZTYAKMNLDI_MFDSSOLXINH__FS^\WQGHGI^C@E[A_CF\AQLDQ\BTMPLDFNVUQ_VM Date: Sat, 23 Feb 2008 08:47:43 -0800 Xref: g2news1.google.com comp.lang.ada:20029 Date: 2008-02-23T08:47:43-08:00 List-Id: "Robert A Duff" wrote in message news:wcc63wfpus7.fsf@shell01.TheWorld.com... > writes: > >> My concern is dependency management. > > OK, but I still don't fully understand what you're getting at. > You said elsewhere in this thread that you are NOT concerned with > recompilation costs. That's good -- recompilation cost should > primarily be an implementation concern. > Sometimes recompilation costs are important. This is true for very large software systems where one does not want to recompile the entire system for one change somewhere way down in a function within one package body. > I'm guessing that your point has nothing to do with "compilation" at > all, separate or otherwise. It has to do with the organization of the > program into separate source files -- specifically separation of spec > and body (interface and implementation, to use more language-neutral > terms). Right? > Right. My primary concern, in this discussion,is with dependency management. > > OK, so you like having textually separate spec and body, > as do I. But what specific advantages are you talking > about in this thread? > > Readability? That is, when looking at a client of A, you don't > need to worry about X,Y,...S. This is good, but it's got little to do > with separate compilation. > In my view, it does. The less code I have to look at to make a change or to understand the code, the better. Granted, this does not always work as well as I might like, but it frequently is of value. > Source modification? A change in X could introduce a bug > into a client of A -- so there really _is_ a dependency > in that sense. > However, the dependency is at the iimplementation level, not at the specification level. > One advantage of Ada over some languages (e.g. C) is that the > implementation can know what source files are part of each program, > by following the with clauses. I really hate having to write a make > file that lists out all the .o files that need to be linked together -- > Ada allows that to be completely automated (that's what gnatmake does). > Well, Yes. If, in one of my separately compiled subprograms within a package body Q, uses a depth-search routine from a parent package specification K, and we decide to use the breadth-search instead, there is no need to alter any part of the package specification of Q. It remains stable. This becomes an architectural issue, as well. The more stable my architecture when a change is made to some element of that architecture, the better for my overall design. > Something else? > > Note that Ada requires some implementation details to appear in the > package spec -- namely, the stuff that goes in the private part, plus > the with clauses needed by that private part. That's ugly, IMHO. > Modula-2 solved that problem through the use of opaque types. I often code opaque types in Ada using access types. This eliminates any dependencies at the specification level, in many cases. As you know, the private part of a package was a compromise that allows separate compilation. We can even create a tagged type as an opaque type, thereby hiding any implementation details and still making that type extensible. This was difficult in Modula-2, so the designers of Modula-3 also had to make some compromises. Engineering is always about trade-offs between conflicting solutions. Java certainly has its share of trade-offs. > > Shrug. I don't use "is separate" much. Child packages are almost > always better, because you can separate the spec _and_ the body, > and because the parent need not know about the child. Child packages > provide the same advantage of being able to "push down" the > dependencies. > I did not mention Child packages, but you are certainly correct that they are a powerful contributing solution to this issue. In particular, private children are a great benefit. However, in very large software systems, a million SLOC or more, "is separate" continues to play an important role. As noted earlier, specifications should be an architectural concern, and the more stable an architecture, the better. Implementation should be dependent on architecture, not the other way around. When I want to change the upholstery in my car, I don't want to have to alter the architecture of that car. I don't want the performance of the car to depend on whether I choose Zebra seat covers or chartreuse trim on green Naugahyde. >> I don't think this is possible in Java, Eiffel, or C#. > > It's possible using interfaces. Clients of an interface do not depend > on classes that implement the interface, any more than clients of an Ada > package spec depend on its body. You suggested otherwise elsewhere in > this thread, but I think you're wrong, or else I'm misunderstanding what > you mean by "depend". > > Interfaces are more flexible than spec/body in that they allow multiple > "bodies". And of course Ada 2005 has interfaces. Note that an > interface will typically be declared in a package spec with no > corresponding body. > Even with an interface, a la Java, once the interface is implemented, the children dependent on that unit will be dependent on the implementaion, not on the interface. And Java still has no way of separating the specification of that implementing class from its implementation. In another forum (comp.lang.programming) someone submitted an example to show how interfaces would solve this problem, but the example did not separate interface from implementation.. > > Eiffel has separate specs and bodies -- except that the spec is > automatically generated from the body, rather than being written by > hand. I prefer to consider the spec to be a source file in its own > right, as in Ada, but it's not _that_ different from Eiffel. > Yes. In Ada, the specification is most certainly a separate source file. As noted earlier, the specifications and the relatioships between specifications, represent the overall architecture of the software system. I'll take another look at Eiffel, a language design I do admire, and examine this in more detail. However, at my present understanding, the implementation and specification do not present the same independence one finds in Ada. Perhaps someone will post an example. Thanks for your details reply. Richard