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!newssvr19.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: 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: newssvr19.news.prodigy.net 1203751725 ST000 70.134.114.51 (Sat, 23 Feb 2008 02:28:45 EST) NNTP-Posting-Date: Sat, 23 Feb 2008 02:28:45 EST Organization: AT&T http://yahoo.sbc.com X-UserInfo1: O@Y[R^[GZRRER_H]]RKB_UDAZZ\DPCPDLXUNNHDK@YUDUWYAKVUOPCW[ML\JXUCKVFDYZKBMSFX^OMSAFNTINTDDMVW[X\THOPXZRVOCJTUTPC\_JSBVX\KAOTBAJBVMZTYAKMNLDI_MFDSSOLXINH__FS^\WQGHGI^C@E[A_CF\AQLDQ\BTMPLDFNVUQ_VM Date: Fri, 22 Feb 2008 23:29:13 -0800 Xref: g2news1.google.com comp.lang.ada:20013 Date: 2008-02-22T23:29:13-08:00 List-Id: "Ray Blaak" wrote in message news:ur6f4sb5l.fsf@STRIPCAPStelus.net... > writes: >> The issue is about dependencies. When the class definition and the >> class implementation are in the same file, any dependent units will >> have to be compiled when there is a change in that file. I don't >> see any capability for managing this kind of dependency in Java. > RB> In practice it's not an issue. Compilation is cheap. RB> For small software systems this might be true. However, for large systems this is not true. I am thinking in terms of software projects that require over a million lines of source code and a lot of library units where the dependencies are significant. For systems of this magnitude, where many different programmers are working on the project, compilation is not cheap. RB> RB> But there is a way to manage explicit dependencies: express the public facing RB> APIs in terms of interfaces with implementation classes that truly hide the RB> actual implementation. RB> I considered Interfaces. They appear, at first glance, to be a solution. However, they fall short of what we are seeking here. Once the Interface is implemented, the rest of the software still depends on that implementation and there is no model of separate compilation at that point where one can separate the specification from the implementation. The dependency becomes bound to the implementation of the Interface not to the Interface abstraction. RB> RB> This gives a strict separation that gives you the control you were looking RB> for.Whether that is as convenient or not as Ada is another debate. RB> It is not a matter of convenience. It simply falls short. RB> RB> The issue is simply not that serious, partially due to Java's dynamic loading RB> abilities. I can drop a new version in of my library JAR in somewhere, and if RB> the public API signatures have not actually changed I do not in fact need to RB> recompile. RB> RB> In practice however, you do, because it's easy and it catches any unexpected RB> API changes. But one was still doing "separate compilation". RB> But not managing dependencies very well.