Re: Idiom for a class and an object in Ada

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

Matthew Heaney wrote:
> 
> You still haven't explained why TYPE Blivet is tagged and nonlimited.
> 
> 
I would have a)thought that was clear and b) mostly irrelavent to my
question. Since one *can* use a tagged type (natural for extension,
etc.) then what does one do when declaring objects of that type?
Limited or not, you still have to declare them somewhere. Why tagged?
Why not? Its a language feature and I'm curious about what is the
preferred idiom for doing so. Or is it your view that tagged types
should never be used?

> 
> 
> 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.
> 
And just as extensible. How do I get my Big_Shiny_Blue_Blivet from the 
limited, indefinite declaration?

> 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.
> 
So if I may interpolate, your preference would be to put the object
declaration in the package body of the package that creates the class?


> 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):
> 
Let's just say "Because I don't feel like it." It would give me problems
with things having nothing to do with Ada and I don't see any need to do
so since a declaration of "Object : Class ;" is totally sufficient for
the job. Keep in mind, I'm not asking about a dozen different style
issues - I'm asking about the preferred scope for a fixed set of static
"objects" (in the OO sense) when one is following the OO methodology.

With or without access types and with or without functions returning the
object, the object has an existence within some scope. It seems to me
that the choices are:

Somewhere within the package spec that defines the "Class"
Somewhere within the package body that defines the "Class"
In a child package of the parent defining the "Class"
In several child packages (one for each object) of the parent defining
the "Class"
In some unrelated library level package wherein presumably one might at
least group together related declarations.
The main program

Even if you do it with some limited and indefinite type because you have
some dislike of tagged types, you still have to declare it somewhere. An
access object only provides a level of indirection so the access object
could be in the package spec, the body, one or more child packages or a
completely unrelated library level package or the main program.


> 
> So take your pick!  In all cases, the objects are declared
> statically, which satisfies your primary constraint.
> 
> 
Well, I can and do take my pick on a regular basis. The question on my
mind was "Is there a generally accepted Ada idiom when implementing the 
OO Design of some class with a limited set of static objects?" You've 
shown one method - albeit, one that avoids the customary tagged records 
designed into Ada to support OO programming. (Given the texts I've 
looked over on OO programming in Ada - they tend to lean towards that 
idiom rather than other possible techniques.)

The question in my mind from the OO Design in Ada texts has been because 
the texts usually discuss all the issues of developing classes, but in 
their limited examples, they usually declare the objects within the 
scope of the main program. Presumably, a whole system would eventually 
be rolled up into one big class with one big object declared at the main 
program level. Since this is not always the case nor is it always 
desirable, my question was about the right idiom to employ when I 
*don't* have the objects all defined in the main program or on the fly 
in dynamic situations.

I hope this clarifies what I was looking for.

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