Re: Idiom for a class and an object in Ada

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

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message 
news:9175719.eWmeGlFrVu@linux1.krischik.com...
> Marin David Condic wrote:
>
>> Suppose I have a class with one or a limited set of objects. The objects
>> are "global" in the sense that they hang around from program startup
>> thru the entire life of execution. An example would be an A/D Converter
>> class - My little control box might have 3 or 4 A/Ds in it - they're
>> always there and I want the data associated with them to be static (not
>> declared on the stack.)
>>
>> Question: What is the preferred Ada idiom for defining such a creature?

See my previous post.  You could either declare the known instances in the 
package itself:

package AD_Converters is
   type AD_Converter (<>) is limited private;
   ... -- ops

   function Huey return AD_Converter;
   function Dewey return AD_Converter;
   function Louie return AD_Converter;

end AD_Converters;

The other possibility is to declare each function as a child:

package AD_Converters.Huey_Converters is
   function Huey return AD_Converter;
end;

Alternatively, you can hide the package like this:

function AD_Converters.Huey return AD_Converter; --spec

private package AD_Converters.Huey_Converters is
   Huey : AD_Converter;
   .. --whatever else is necessary for the Huey object
end;

with AD_Converters.Huey_Conveters;
function AD_Converters.Huey return AD_Converter is --body
begin
   return Huey_Converters.Huey;
end;


Whether you declare all the objects up in the root package or as child 
functions is determined by whether your application always manipulates the 
objects as a group (that's the case in the genealogy example), and how many 
unique dependencies each object has (if the library units you need to make a 
Huey object are the same as the library units you need to make a Dewey 
object, then they might as well be declared together).