Re: User-defined assignment

[swrinde!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!netnews.upenn. edu!uofs!guinness.cs.uofs.edu!beidler@gatech.edu (Jack Beidler)]

In article <1992Oct22.221917.15169@cfmu.eurocontrol.be>, stef@cfmu.eurocontrol.
be (Stef Van Vlierberghe) writes:
|>   ...
|> I believe  that the real cost is the danger of people  falling for the
|> cheap-but-unsafe  solution of non-limited  non-finalized types, rather
|> than going for the elaborate-but-sound approach (it happens!).
|> 
|> The  second-best  problem is the one with  generics.  Of the thousands
|> (or  more ?)  generic  Abstract  Data  Type  packages  (lists,  rings,
|> queues,  stacks,  maps, etc...  ) Very few have limited  formal types,
|> perhaps inspired by Booch's approach in Software  Components with Ada.
|> In Ada9X we expect to get an automatically finalized type X, but if we
|> also want a list of X's, ring of X's,  etc...  we need to convert  the
|> generics to use procedure a limited  private  generic  formal type and
|> generic  formal  function  "=" and  procedure  ASSIGN,  or  build  the
|> composite abstraction ad-hoc.
|> 

I wonder if Booch had to do it all over again if he would have used
limited private types.  I have a full set of components that I use in my
courses.  We have adopted the following naming convention 

             component_inst_vis

where "component" is the type of component, "inst" is the type of instantiation
parameter (Pt or Lpt for private or limited private), and "vis" is the
method of visibility (Pt or Lpt).  Three packages are made available for
each component.  For example, the stack packages are:

    Stack_Pt_Pt, Stack_Pt_Lpt, and Stack_Lpt_Lpt.

Note Stack_Lpt_Pt makes no sense.  Pt assumes bound and Lpt assumes managed
storage.

Whenever a package makes a limited private type available, it also supplies
three procedures and one function,

   Zap (nulls the component), Copy (Source, Target), 
   Move_And_Reset (Source, Target) and the function "="

We also require that when a package is instantiated with a limited private
type, the client must also supply Zap, Copy, Move_And_Reset, and "="
for that object, as in,

   generic
      type Object_Type is limited private;
      with procedure Copy ( Source : in     Object_Type ;
                            Target : in out Object_Type ) ;
      with procedure Move_And_Reset ( Source : in out Object_Type ;
                                      Target : in out Object_Type ) ;
      with procedure Zap ( Source : in out Object_Type ) ;
      with function "=" ( Left, Right : Object_Type ) return boolean ;
   package Stack_Lpt_Lpt is

     type Stack_Type is limited private ;

        . . .

By requiring that limited private types be supplied with the correct resources
the client is not longer hindered by a lack of ":=" .

Besides Copy, Zap, and Move_And_Reset, components may also have a 
sharing mechanism if the software developer feels it may be accomplished
in a safe and appropriate manner.  When we supply sharing in our
component packages, we supply them with typical support procedures, like
Share, Unshare, Is_Shared.  Usually when a representation is shared, we
do not allow items to be removed from the structure.  This eliminates a 
lot of coding.

Our experience has been that the support above is sufficient.  I'd appreciate
hearing about other approaches.  I am also looking for an example where the
Zap-Copy-Move_And_Reset-Share support is not sufficient for providing access
to a limited private type.

-- 
+------------------------------------------------------------------+
|  John (Jack) Beidler				                   |
|  Prof. of Computer Science Internet: BEIDLER@JAGUAR.UOFS.ED      |
|  University of Scranton              beidler@guinness.cs.uofs.edu|
|  Scranton, PA 18510	      Bitnet : BEIDLER@SCRANTON            |
|                                                                  |
|          Phone: (717) 941-7446	 FAX:   (717) 941-4250     |
+------------------------------------------------------------------+