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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,39e272d357c68416 X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Is Apex dead as an environment for Ada & Java? Date: 1999/12/01 Message-ID: <38455ACF.48F71808@hso.link.com>#1/1 X-Deja-AN: 555366035 Content-Transfer-Encoding: 7bit References: <11f733ec.57d88b68@usw-ex0107-042.remarq.com> <384127A5.61431A14@dowie-cs.demon.co.uk> <0a0133f8.3baf10c0@usw-ex0101-001.remarq.com> <81s370$7am$1@nnrp1.deja.com> <04d17460.3bc3fd68@usw-ex0101-008.remarq.com> <38441AAE.29B2D8@hso.link.com> <38a139f2.d0489d23@usw-ex0107-043.remarq.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Scientific & Technical Services Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-12-01T00:00:00+00:00 List-Id: jim_snead wrote: > > In article <38441AAE.29B2D8@hso.link.com>, "Samuel T. Harris" > wrote: > > One way to eliminate circular dependencies is to insure > > each interface is in a separate subsystem from its users. > > For instance, say I have two major code collections called > > X and Y. They both interface with each other, so X provides > > an interface which Y uses and Y provides an interface which > > X uses. If X's interface in packaged with X's code and similarly > > for Y, then we have a mutual import dependency. > > However, if I split the interfaces out into separate subsystems, > > say X_Iface, X_Model, Y_Iface, and Y_Model, then I eliminate > > the circular dependencies. If all models have a separate Iface > > subsystem, then I never get circular dependencies no matter > > what the interface topology. This also alows a natural release > > strategy of releasing updated interfaces independently. This > > allows all models to progress to the new interfaces in succession. > > This architecture is very flexible to a variety of scheduling > > paradims. > > So specs go into the IFace and bodies go into the Model subsystems? > One could do that, and I have considered this idea on several occasions to limit recompilation impact imposed by new releases, but that is not what I meant. The interface is a different package from the model. The interface spec and body units go into a separate subsystem from the model spec and body units. Since you mentioned the idea of putting unit specs and bodies into separate subsystems, I'll elaborate on this as well. Even the advanced incremental compiler provided with Apex provides little benefit when a new release is being made. Conventional code organization keeps the spec and body of a unit in the same place. On the surface, this seems a natural organizational scheme. However, when a new release is made because of strictly body changes, a new spec is also released. This causes an unneccesary compilation impact. Looking deeper into the problem, we can realize that the separation of the spec and body in Ada provides an equivalent opportunity to separate in code organization. Keeping the specs and bodies in separate subsystems yields some important benefits. 1) A view only needs to import spec views. Body views need not be imported at all. Body views do need to be listed in the link_with_configuration. One can envision a customization which manages link_imports just like, but separate from, regular view imports. 2) I can change the link_imports at will and suffer no compilation effects (unless inline subprograms are in use). I only have to relink. This allows me to rapidly try different implementation options using a single set of package specs. This organization scheme also suffers from the following disadvantages. 1) The separation of spec and body into two different areas makes it clumsy for the developer. Two naturally intimate units do not reside in the same place. Of course this issue is mitigated with the superb navigation facilities and can be handled by using "working" subsystems whose views use symbolic links to "collect" related stuff together into one place. 2) Immature code in the early stages of development will not realize the benefits noted above. The specs of such code change nearly as often as the bodies. Only mature code with stable specs are candidates for this scheme. I have given this issue much thought over the years. I originally wanted to simulate the old R1000 facility of spec views vs load views. A spec view had only uint specifications. It could be related to many different load views which had the unit bodies. The load view also had specs, but they had to have the same content. Since the spec view and load views were in the same subsystem, this scheme did not suffer from the clumsiness of their separation. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!"