Re: problem with abstract types

["Robert I. Eachus" <rieachus@attbi.com>]

Ulrich Eckhardt wrote:

> No. openRegistry is first defined abstract and then implemented
> as openRegistry(reg : in out file_registry; ..) and
> openRegistry(reg : in out win_registry; ..) .

Error, C++ thinking detected.  In Ada, unless you really have use them 
for some reason, avoid access types.  Access types IMHO, should be 
buried in packages which implement container abstractions and never show 
up in package specifications or user code.

If you change your specification to:

package registry is
   type registry is abstract tagged limited private;

   function openRegistry(Priviledge: in Sys_Access
                         Registry_Name: String)
   return registry is abstract;
   [..]
   exception Registry_Error; -- if you must.
end Registry;

In the two (or more!) child packages:

   function openRegistry (a      : in sys_access;
                         p_name : String)
       return file_registry is  --change as necessary.
     Reg: file_registry;
   begin
     -- any non-default actions here...
     return Reg;
   end fileRegistry;

Then your test program becomes:

  with registry; use registry;
  procedure main is
    declare
      reg := openRegistry(CLASS_USER,"registrytest");
    begin
      null; -- for now.
    exception
      when Registry_Error => -- do something useful like printing
                             -- location.
      when others => -- be prepared for anything in a test program...
    end;
  exception
    when others => -- catch finalization bugs here.
  end main;

Now you might think that Reg is declared inside a function and that it 
will either need to be declared on the heap, or copied during the 
return.  LET THE COMPILER WORRY ABOUT ALL THAT.  In practice the 
compiler will probably build the return value in place if it can inline 
openRegistry.  But it is not your problem, and a lot of unnecessary code 
goes away.

Also you will note that I got rid of any need for Unbounded_String.  It 
may be that some of the individual implementations of openRegistry will 
need to use Unbounded_String, but if the name never changes, you 
probably won't.  In any case, make things easy for the user of the 
abstraction.  In this case it also makes it easier for the implementor.