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:jUNdd.3252$5i5.107@newsread2.news.atl.earthlink.net...
> 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?

That's the wrong question.  The question should be, Why?

Do you need type extension?  Do you need polymorphism (dynamic binding)?  If 
no, then clear you don't need a tagged type.



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

I'm saying they should be used when you need type extension and dynamic 
binding.  Otherwise you can use a non-tagged type.



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

If you need type extension, then clearly you need a tagged type.  But that 
is orthogonal to the issue of limitedness and indefiniteness:

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

package Blivets.Big_Shiny_Blue is
   type Big_Shiny_Blue_Blivet (<>) is new Blivet with private;
...
end;



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

Yes.  Or the objects could be a declared child package.  As I showed in 
another post, you can even make the child package private, and make the 
selector function a public child.


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

I don't know what an object is "in the OO sense" or what "OO methodology" is 
(I just call it "programming"), but if these are a fixed set of well-known 
objects, then I would declare the type as limited and indefinite (or tagged, 
if necessary), and declare the instances either in the package itself, or in 
(possibly private) child packages.


> Even if you do it with some limited and indefinite type because you have
> some dislike of tagged types,

No, I have no dislike of tagged types.  I have a dislike of using tagged 
types where a non-tagged type will do.  I have a dislike of using 
non-limited types when a limited type will do.

The issue of taggedness is orthogonal to the issue of limitedness is 
orthogonal to the issue of indefiniteness.  See my example above.

-Matt