Re: Idiom for a class and an object in Ada

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

Dmitry A. Kazakov wrote:
> Anyway, I see nothing criminal in the package name "AD_Converter_Class".
> The names should reflect the application domain, rather than language
> gears. With some minor exceptions, which IMO always more or less reflect
> language deficiencies (I mean XXX_Ptr, XXX_Type etc), Hungarian notation
> and company is an evil thing. I have no problem to read AD_Converter_Class
> as "a class of physical devices, described in general by this package".
> Whether that class is mapped to a type or to a class of related types is a
> design decision.
> 

I didn't want to get hung up on names or the chosen example of A/D 
converters or any of that, so folks should just substitute whatever 
names they consider in good taste. I paint with a broad brush most of 
the time.

Consider it this way: You go to an Object Oriented Design class and 
Grady Booch starts explaining to you about a "Class" with "Attributes" 
and "Methods". Having learned all that, you basically discover that the 
corresponding Ada idiom for a class would be a package with a tagged 
type and a bunch of functions & procedures to act as the methods. (Am I 
wrong about that? Is there some other preferred idiom for implementing a 
'class' in Ada?)

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.

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?


> 
> My personal preference is (b) - child packages. When necessary, one can
> additionally create an assembly package with renames of converters
> instances from different packages:
> 
> with AD_Converter_Class.Diamond;
> with AD_Converter_Class.AX10410A;
> ...
> package AD_Converter_Class.This_Board_Hardware is
>    AD_1 : AD_Converter_Class.Diamond_MM.AD;
>    AD_2 : AD_Converter_Class.AX10410A.AD;
>    ...
> 

And there we get an answer to at least one preferred method of doing 
this. I have used this idiom myself in the past.

I've noticed that GtkAda seems to use an idiom wherein they declare all 
the stuff relating to a window in a package spec, followed by an access 
type declaration that then exercises an allocator to create the single 
object of that window. It works and I have no grief with it, except that 
in the particular case of interest, I don't want to use an allocator. Is 
there a consensus that this ought to be the idiom of choice when you 
*don't* care about the allocator?

MDC
-- 
======================================================================
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
======================================================================