Re: Idiom for a class and an object in Ada

[Marin David Condic <nobody@noplace.com>]

Actually, the A/D converter might be used to read a whole variety of 
values. You multiplex the inputs.

Maybe my question isn't really clear. I'm thinking of something of the 
flavor:

package AD_Converter_Class is

     type AD_Converter is tagged private ;

     procedure Some_Op_Like_Read_The_AD_Converter (
         Converter : in out AD_Converter) ;

end AD_Converter_Class ;

Don't get hung up on it being an AD converter. The question relates more 
to the proper idiom for a class that might have one or a few static 
objects (as opposed to anything I might dynamically create and destroy 
through the life of a program) Where would the best place be to declare 
the objects of that class assuming that the storage must be static? You 
could do this:

package AD_Converter_Class.AD_Number_One is

     AD : AD_Converter ;

end AD_Converter_Class.AD_Number_One ;

Or you could do something like:

with AD_Converter_Class ;
package All_My_Global_Junk is
     AD1 : AD_Converter_Class.AD_Converter ;
     AD2 : AD_Converter_Class.AD_Converter ;
end All_My_Global_Junk ;

Or you could do something like:

with AD_Converter_Class ;
procedure The_Main_Program is
     AD1 : AD_Converter_Class.AD_Converter ;
     AD2 : AD_Converter_Class.AD_Converter ;
begin
     stuff ;
end The_Main_Program ;

Or you could declare them in some package that used them - but that 
might be lots of possible packages. The main program option has 
weaknesses in that the objects may need to be visible across a variety 
of tasks. I generally don't like a "dumping ground" package that 
declares all the global storage - maybe if it might be limited to just 
objects of the one class it might seem more palatable. That's not too 
different than creating a child package for the objects. One child 
package for all objects? One child package per object?

What is the preferred Ada idiom for something like this?

MDC


Matthew Heaney wrote:

> Jeffrey Carter <spam@spam.com> writes:
> 
> 
>>Marius Amado Alves wrote:
>>
>>
>>>generic
>>>   Line : Number;
>>>package AD_Converter is
>>>   function OK return Boolean;
>>>   function Get return Value;
>>>end;
>>>package Heat is new AD_Converter (123);
>>>package Noise is new AD_Converter (456);
>>>package Wind is new AD_Converter (789);
>>>-- You can't get more "static" than that!
>>
>>Or simple. Or Ada-like. The other suggestions look too much like C++
>>for my taste.
> 
> 
> 
> Too much code bloat.  There's no reason AD_Converter needs to be a
> generic, if the objects of that type are known apriori:
> 
> package AD_Converters is
>    pragma Elaborate_Body;
> 
>    type AD_Converter (<>) is limited private;
> 
>    function OK (Converter : AD_Converter) return Boolean;
>    function Get (Converter : AD_Converter) return Value;
> 
>    function Heat return AD_Converter;
>    function Noise return AD_Converter;
>    function Wind return AD_Converter;
> 
> private
> 
>    type AD_Converter (Line : Number) is limited record ...;
> 
> end AD_Converters;
> 
> 
> package body AD_Converters is
>    ...
> 
>    Heat_ADC  : AD_Conveter (123);
>    Noise_ADC : AD_Converter (456);
>    Wind_ADC  : AD_Converter (789);
> 
>    function Heat return AD_Converter is
>    begin
>       return Heat_ADC;
>    end;
> 
>    function Noise return AD_Converter is
>    begin
>       return Noise_ADC;
>    end;
> 
>    function Wind return AD_Converter is
>    begin
>       return Wind_ADC;
>    end;
> 
> end AD_Converters;
> 
> 
> Alternatively, you could declare the objects each in their own private package:
> 
> function AD_Converters.Heat return AD_Converter;
> 
> private package AD_Converters.Heat_AD_Converters is
>    Heat_AD_Converter : AD_Converter (123);
>    ... -- whatever else
> end;
> 
> with AD_Converters.Heat_AD_Converters;
> function AD_Converters.Heat return AD_Converter is
> begin
>    return AD_Converters.Heat_AD_Converter;
> end;
> 
> 
> This would be useful if each AD_Converter object had distinct library
> dependencies.  (Although it might not matter that much anyway, since
> such dependencies would have been limited to the body.)

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Power corrupts.  Absolute power is kind of neat"
         -- John Lehman, Secretary of the Navy 1981-1987
======================================================================