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/11/30 Message-ID: <38441AAE.29B2D8@hso.link.com>#1/1 X-Deja-AN: 554954012 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> 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-11-30T00:00:00+00:00 List-Id: jim_snead wrote: > > In article <81s370$7am$1@nnrp1.deja.com>, mike_zebrowski@my-deja.com > wrote: > > Apex subsystems help prevent circular references. > > Ada95 naming coventions do not. > > Mike Zebrowski > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > I found out that Apex allows mutually importable > subsystems, which is what I think the > circular refers to. So much for strict enforcement. Well, it is strict. Mutually imports require that ALL the mutally dependent views be managed collectively. In other words, if views x, y, and z are mutually dependent, then I cannot make a release of view x by itself. I have to make a relase based on x, y, and z at the same time. They are, in practical terms, a single logical subsystem split between multiple actual subsystems. So they are much more restricted than regular, non-circular import dependencies. 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. > > * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * > The fastest and easiest way to search and participate in Usenet - Free! -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!"