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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,58f5085c2edafcfe X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wn11feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: Design - cyclic dependencies Reply-To: anon@anon.org (anon) References: <1193401560.389194.282030@o3g2000hsb.googlegroups.com> X-Newsreader: IBM NewsReader/2 2.0 Message-ID: <8lvUi.281277$ax1.113866@bgtnsc05-news.ops.worldnet.att.net> Date: Sat, 27 Oct 2007 00:09:40 GMT NNTP-Posting-Host: 12.64.60.119 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1193443780 12.64.60.119 (Sat, 27 Oct 2007 00:09:40 GMT) NNTP-Posting-Date: Sat, 27 Oct 2007 00:09:40 GMT Organization: AT&T Worldnet Xref: g2news2.google.com comp.lang.ada:2600 Date: 2007-10-27T00:09:40+00:00 List-Id: Ada mostly uses a Modular Design Structure. The cyclic package structures are legal but a should not be used unless the algorithm requires it. Plus, they can cause "Bounded (Run-Time) Errors" [ RM E ( 10 ) ] which can result in deadlock for the elaboration or they can raise a Program_Error during run-time. A common way around the cyclic design structure in using external packages is to use the "pragma Export/Import" statements. Now there are some algorithms that use cyclic design. These should limit all the cyclic routines to a single package. Such as in a procedure / sub-procedures design that follows: package Test is procedure A ; end Test ; package body Test s procedure A is procedure B is procedure C is begin -- C A ; end C ; begin -- B C ; end ; begin -- A B ; end A ; end Test ; But the best way is to re-write the cyclic algorithms to use the modular design structure. In your example the type T should be in another package called may be C. In this design, the modular structure could be is maintain. package A with B, C ; package B with C ; -- -- c.ads: -- package C is type T is new Integer ; end C ; In <1193401560.389194.282030@o3g2000hsb.googlegroups.com>, Maciej Sobczak writes: >Consider: > >-- a.ads: >package A is > type T is new Integer; > procedure P; >end A; > >-- a.adb: >with B; >package body A is > procedure P is > X : T; > begin > B.P (X); > end P; >end A; > >-- b.ads: >with A; >package B is > procedure P (X : A.T); >end B; > >-- b.adb: >package body B is > procedure P (X : A.T) is > begin > null; > end P; >end B; > >There are two logical modules A and B, implemented as packages. >There is no cyclic dependency between the specifications of these >packages and the code is legal. >Still, there is a design-level cyclic dependency between the whole >modules in the sense that A depends on B (A calls some operation of B) >and that B depends on A (B uses some type from A). > >Being legal does not imply being good and therefore I ask: do you >consider this kind of design-level cyclic dependency to be acceptable? >If not, what measures would you recommend to correct it? >Extracting T to another package is probably the only reasonable >option, but then there are variants of it (child or sibling package, >etc.). > >-- >Maciej Sobczak * www.msobczak.com * www.inspirel.com >