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!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!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: Sun, 24 Feb 2008 12:20:02 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <7xJvj.7420$Ru4.4246@newssvr19.news.prodigy.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1203873604 18970 192.74.137.71 (24 Feb 2008 17:20:04 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 24 Feb 2008 17:20:04 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:gaUH6/O3BYNEqEO96QriU68qHZM= Xref: g2news1.google.com comp.lang.ada:20041 Date: 2008-02-24T12:20:02-05:00 List-Id: writes: > "Robert A Duff" wrote in message > news:wccbq679zah.fsf@shell01.TheWorld.com... > > In the example you provided (shown below) you did defer the with clause > for the Package P1 to the package body of P2. This illustrates my point. > If the specification for P1 changes, only the body for P2 needs to be compiled. > Had the with clause been at the specification level for P2, and had the > specification for P1 changed, the entire package would have had to be > compiled. Earlier, you said that this conversation was not about compilation costs, but now you seem quite interested in compilation costs. That's OK. So let's talk about compilation costs. ;-) I think you miss the point of my example (still shown below). Package P1 is the interface, and P2 is the implementation of that interface. P2 is NOT a client of P1, it's an implementation of P1! There are perhaps 37 clients of P1, not shown. The question is, if we modify the implementation (i.e. P2) do we need to recompile those 37 clients. The answer is "no". As you point out, if you change the interface, you have to recompile the implementation. That's true in my example. It's also true if the interface/implementation is split in the more traditional Ada way (spec/body). The issue of recompiling the spec of P2 is irrelevant, since it's empty! > I think the same is true for Java. If the specification for the Interface is > changed, everything needs to be recompiled. In Ada, by deferring the > with clause to the package body, we only need to re-compile the body. > > So, I think your example actually supports my original assertion. The > essential point is that changes in the specifications for a package (or > a Java class) should not require re-compilation of the dependent > specifications. Only the implementations should be dependent on > other specifications. This has the effect of keeping the high-level > architecture more stable. > > package P1 is > type Iface is interface; > ... declare some abstract procedures ... > end P1; > > package P2 is > pragma Elaborate_Body; > -- Note that this package spec can be entirely empty (except we > -- need the pragma so we are allowed to have a body). > -- So this package spec isn't defining any interface to > -- anything at all! > end P2; > > with P1; > package body P2 is > type Impl is new P1.Iface with ... > ... override procedures ... > ... > end P2; > > -- No body for P1! > > Then the client can "with P1", and call operations on Iface objects > without knowing anything about package P2 (neither spec nor body). > There is no dependence of clients on P2 (unless I'm misunderstanding > what you mean by "depend"). Let me try a more concrete example -- the trusty stack example. First, the traditional Ada way, using what you like to call "opaque" types: package Stacks is type Stack is private; procedure Push(...); ... private type Stack_Rec; type Stack is access Stack_Rec; end Stacks; package Stacks is type Stack_Rec is record ...; procedure Push(...) is begin ... end Push; ... end Stacks; If we change the implementation of the stacks abstraction (i.e. the body of package Stacks), we do not normally need to recompile the clients. We can accomplish the same thing with interfaces. I'll use a child package this time, just for fun: package Stacks is type Stack is interface; procedure Push(...) is abstract; ... end Stacks; package Stacks.Implementation is type Stack_Impl is new Stack with private; private type Stack_Impl is ...; overriding procedure Push(...); ... end Stacks.Implementation; package Stacks.Implementation is procedure Push(...) is begin ... end Push; ... end Stacks.Implementation; If we change the implementation of the stacks abstraction (i.e. the package Stacks.Implementation -- spec or body, it doesn't matter), we do not normally need to recompile the clients. Both ways of writing the stacks abstraction have the same property -- the 37 clients that say "with Stacks" do not need to be recompiled when we modify the implementation. The second example matches what is normally done in Java, except that in Java, we wouldn't split the implementation into two parts. Note that in the second example, that split has no value, since there are no clients of Stacks.Implementation. In fact, in some cases, we can choose to move all of the code from the spec of Stacks.Implementation to its body (as I did in my P1/P2 example), making the spec empty. (I'm glossing over the fact that there probably needs to be some sort of factory for creating stack objects, but that's not relevant to my point.) - Bob