Re: Idiom for a class and an object in Ada

["Matthew Heaney" <mheaney@on2.com>]

"Marin David Condic" <nobody@noplace.com> wrote in message 
news:UUsdd.3499$ta5.1160@newsread3.news.atl.earthlink.net...
>
> So now you want to say "I have this 'class' called a Blivet and I might 
> want to have a "Blue_Blivet" and a "Shiny_Blue_Blivet" and a 
> "Big_Shiny_Blue_Blivet" so the natural thing to do is make a 'class' from 
> a package and a tagged type and a bunch of subprograms.

You still haven't explained why TYPE Blivet is tagged and nonlimited.


> Having done that, you find you have a constraint: For reasons having 
> nothing special to do with Ada, you want all the data for the 'objects' of 
> that class to be in static storage and not involve access types and all 
> that. No generics because of code bloat and other issues. Any other issues 
> such as private vs limited private are all just sidebars having nothing 
> special to do with the question at hand. You can get what I describe with 
> a simple declaraion of "My_Blivet : Blivet;" put somewhere at the Library 
> level. To repeat my question:
>
> What is the preferred Ada idiom (when talking about Object Oriented 
> methodology) for declaring those objects?

To repeat my answer: declare the TYPE as limited and indefinite, and declare 
selector functions that return references to the statically declared 
instances.  Just like Text_IO.

Limited types are passed by reference, so one way to do sans access types is 
like this:

package Blivets is
   type Blivet (<>) is limited private;

   procedure Op (B : Blivet);

   function My_Blivet return Blivet;
private
   type Blivet is limited record .. end record;
end;

package body Blivets is
  ...
  My_Blivet_Object : Blivet;

  function My_Blivet return Blivet is
  begin
     return My_Blivet_Object;
   end;
end Blivets;

Limited types are passed by reference, so neither allocation nor access 
types are necessary.

Note that using access types doesn't imply allocation, so it's not clear to 
me what you have against access types.  Another possibility is to implement 
the type as an access type (so direct pointer manipulation isn't necessary):

package Blivets is
   type Blivet (<>) is limited private;
   procedure Op (B : Blivet);

   function My_Blivet return Blivet;
private
   type Rep_Type is <whatever>;

   type Blivet is access all Rep_Type;
   for Blivet'Storage_Size use 0;

end Blivets;

package body Blivets is
   ...
   My_Blivet_Object : aliased Rep_Type;

   function My_Blivet return Blivet is
   begin
      return My_Blivet_Object'Access;
   end;
end Blivets;

This has the benefit that objects are allocated statically, and all uses of 
pointers are hidden from the user.

Yet another possibility is to expose the access type, but pass the object as 
an access parameter:

package Blivets is
   type Blivet (<>) is limited private;
   procedure Op (B : access Blivet);

   type Blivet_Access is access all Blivet;
   for Blivet_Access'Storage_Size use 0;

   My_Blivet : constant Blivet_Access;
private
   type Blivet is limited record ... end record;

   My_Blivet_Object : aliased Blivet;
   My_Blivet : constant Blivet_Access := My_Blivet_Object'Access;
end Blivets;


So take your pick!  In all cases, the objects are declared statically, which 
satisfies your primary constraint.