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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!emx.utexas.edu
From: hasan@emx.utexas.edu (David A. Hasan)
Newsgroups: comp.lang.ada
Subject: factoring with generics
Message-ID: <45358@ut-emx.uucp>
Date: 8 Mar 91 23:36:10 GMT
Sender: hasan@ut-emx.uucp
Organization: UTexas Center for Space Research
List-Id: <comp.lang.ada>

I have a question that deals with using generic subprograms
inside packages as a means of factoring out common implementation
details of the subprograms exported by the package.

Consider a package that exports similar subprograms to its clients:

PACKAGE p IS
   TYPE someType IS ...;
   FUNCTION f1(arg1,arg2 : IN someType) RETURN someType;
   FUNCTION f2(arg1,arg2 : IN someType) RETURN someType;
END p;

and suppose further that the implementations <f1> and <f2> are the same 
except for one subprogram call.  (For example, elementwise addition 
and subtraction of vectors.)

It occurs to me that it might be wise to implement these
as instances of one generic function (<g_f>, say) which takes the 
crucial differing subprogram as a generic parameter.  
To do this, I could:

   1) put the GENERIC DECLARATION and BODY of <g_f> in the body of <p>.
      In this case, the implementations of <f1> & <f2> would 
      instantiate <g_f>.

      But of course, this is hogwash:  generic instantiations
      are *declarations* and cannot be used to define the
      implementation.  So, as an alternative...

   2) put the GENERIC DECLARATION in the package spec and put the
      BODY in the body of package <p>.  <f1> & <f2> could then
      be declared as instances of <g_f>.  This has the pleasant
      side effect of exporting to my clients a generic function
      which they might find useful.

      This works fine until runtime:  when package <p> is elaborated,
      the instantiations for <f1> and <f2> raise PROGRAM_ERROR,
      since the package body (and therefore the body of <g_f>) has 
      not yet been elaborated.

   3) Implement <f1> and <f2> as "skin" routines which simply
      call two internal (to the body of <p>) instances of <g_f>.

      At this point, the simplicity of it all has been lost.


One additional solution might be to factor <g_f> outside of the package
altogether.  However, <f1> and <f2> are fundamentally part of the
abstraction provided by package <p> and cannot be implemented independently.

Is there some way that I have missed to use generics to factor out common
elements of implementations?
--
 :   David A. Hasan
 :   WRW 402 Univ. of Texas at Austin, Austin TX 78712
 :   internet: hasan@emx.cc.utexas.edu