Re: Design - cyclic dependencies

[anon@anon.org (anon)]

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 <see.my.homepage@gmail.com> 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
>