Idiom for a class and an object in Ada

Idiom for a class and an object in Ada

[Marin David Condic]

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?

I have a package that defines the class - that contains the tagged type 
and any methods. I might:

a) Declare the objects within that "class" package

b) Declare the objects within some child package of the class package

c) Declare the objects in some global "Here's all my static data" 
package (not very tidy)

d) Declare the objects in the main program (not good if they are 
accessed by more than one task and also a kind of dumping ground)

Does anybody have an opinion or experience with doing this? I know what 
I've done in the past, but I'm curious if there is any preferred method 
or idiom for this in the OO paradigm as applied to Ada?

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

Re: Idiom for a class and an object in Ada

[Martin Krischik]

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?
> 
> I have a package that defines the class - that contains the tagged type
> and any methods. I might:
> 
> a) Declare the objects within that "class" package

Yes, within the class body only.
 
> b) Declare the objects within some child package of the class package

If there are a lot of static data, use a private package.

For both: When multi tasking is an issue use a protected type to secure
access to the data.
 
> c) Declare the objects in some global "Here's all my static data"
> package (not very tidy)

No.

> d) Declare the objects in the main program (not good if they are
> accessed by more than one task and also a kind of dumping ground)

No as well. Each package has it

> Does anybody have an opinion or experience with doing this? I know what
> I've done in the past, but I'm curious if there is any preferred method
> or idiom for this in the OO paradigm as applied to Ada?

If you truly thing about OO you would us a singelton class. You know a class
where only one instance exists. Within the singelton class (package body)
you can either use class data or static data. It would not matter since is
is all hidden inside the package body.

With Regards

Martin


-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

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

Re: Idiom for a class and an object in Ada

[Marin David Condic]

So you would do something that looked like this:

package AD_Converter_Class_And_Objects is

     type AD_Converter is tagged private ;

     procedure Some_Op (AD : in out AD_Converter) ;

     AD_Number_1 : AD_Converter ;

private
     --stuff
end AD_Converter_Class_And_Objects ;

Similarly if I had a half-dozen of these puppies? If I had only one, 
you'd want to hide it in the package body and make the package be an 
object instead of a class?

Would there be a reason to prefer making a child package to contain one 
or more objects of the class? Or a separate child package for each object?

There could be plusses and minuses to any given approach. I'm mostly 
wondering what most Ada programmers prefer or tend to use.

MDC



Martin Krischik wrote:

> 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?
>>
>>I have a package that defines the class - that contains the tagged type
>>and any methods. I might:
>>
>>a) Declare the objects within that "class" package
> 
> 
> Yes, within the class body only.
>  
> 
>>b) Declare the objects within some child package of the class package
> 
> 
> If there are a lot of static data, use a private package.
> 
> For both: When multi tasking is an issue use a protected type to secure
> access to the data.
>  
> 
>>c) Declare the objects in some global "Here's all my static data"
>>package (not very tidy)
> 
> 
> No.
> 
> 
>>d) Declare the objects in the main program (not good if they are
>>accessed by more than one task and also a kind of dumping ground)
> 
> 
> No as well. Each package has it
> 
> 
>>Does anybody have an opinion or experience with doing this? I know what
>>I've done in the past, but I'm curious if there is any preferred method
>>or idiom for this in the OO paradigm as applied to Ada?
> 
> 
> If you truly thing about OO you would us a singelton class. You know a class
> where only one instance exists. Within the singelton class (package body)
> you can either use class data or static data. It would not matter since is
> is all hidden inside the package body.
> 
> With Regards
> 
> Martin
> 
> 

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

Re: Idiom for a class and an object in Ada

[Martin Dowie]

Marin David Condic wrote:
> There could be plusses and minuses to any given approach. I'm mostly
> wondering what most Ada programmers prefer or tend to use.

Personally, I would _never_ mix classes (or ADT's) and instances of them 
within the same package or even in the same package hierarchy. Neither would 
I never make data items public. It does lead to some extra lines of code but 
in my experience it makes testing easier and maintenance _much_ easier.

-- Martin

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message 
news:cl39c4$k1j$1@hercules.btinternet.com...
>
> Personally, I would _never_ mix classes (or ADT's) and instances of them 
> within the same package or even in the same package hierarchy.

I suggest you start using Ada95 to program in ... Ada95.

Declare the type as limited and indefinite, and declare selector functions 
to return references to the statically-declared instances.  Just like 
Text_IO.

Re: Idiom for a class and an object in Ada

[Martin Dowie]

Matthew Heaney wrote:
> "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
> news:cl39c4$k1j$1@hercules.btinternet.com...
>>
>> Personally, I would _never_ mix classes (or ADT's) and instances of
>> them within the same package or even in the same package hierarchy.
>
> I suggest you start using Ada95 to program in ... Ada95.


Thanks for the suggestion but I'll pass for now... ;-)

It is a style that was developed pre-95 but it works, has proven itself to 
produce very re-usable code (which embedding 'project specific' instances 
into potentially multi-project class/ADT's won't).

If the ADT/class was indeed total specific to a project and there were 
always only going to be instances X, Y and Z, then fair we might look at a 
different style. But most of the ADT/classes we write just don't fall into 
that category.

It's a style that also works for our 'C' projects (and Ada83 too, of course) 
and it works with all the CASE tools we use too (Teamwork, Real-time 
Studio).

There are too many other "process and procedure fish to fry than changing 
this (all non-Ada related).

-- Martin
 

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message 
news:Oc8dd.2347$ta5.1598@newsread3.news.atl.earthlink.net...
> So you would do something that looked like this:
>
> package AD_Converter_Class_And_Objects is
>
>     type AD_Converter is tagged private ;
>
>     procedure Some_Op (AD : in out AD_Converter) ;
>
>     AD_Number_1 : AD_Converter ;
>
> private
>     --stuff
> end AD_Converter_Class_And_Objects ;


Well, obviously this won't work, since you can't declare object AD_Number_1 
prior to declaration of the full view of private type AD_Converter.

And why did you name the package "...Class_And_Objects".  Don't you mean 
"...Type_And_Objects"?  This is very, very confusing!


> Similarly if I had a half-dozen of these puppies? If I had only one, you'd 
> want to hide it in the package body and make the package be an object 
> instead of a class?

What do you mean "instead of a class"?  Do you mean "type" or "class"?  If 
you mean "type", then why don't you say that?



> Would there be a reason to prefer making a child package to contain one or 
> more objects of the class? Or a separate child package for each object?

Do you mean one or more "objects of the type"?  Why are you saying "class" 
here?  This is very, very confusing!


> There could be plusses and minuses to any given approach. I'm mostly 
> wondering what most Ada programmers prefer or tend to use.

I showed you how to do this in another post.  Declare the type as limited an 
indefinite, and provide functions that return a references to the 
statically-declared objects.  Just like Text_IO.

Re: Idiom for a class and an object in Ada

[Marius Amado Alves]

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

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!

Re: Idiom for a class and an object in Ada

[Jeffrey Carter]

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.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

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

Re: Idiom for a class and an object in Ada

[Marin David Condic]

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

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message 
news:s78dd.2345$ta5.833@newsread3.news.atl.earthlink.net...
>
> 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?

First of all, if we're going to have a conversation, we need to agree on 
terms.

The term "class" in Ada has a very specific meaning.  In Ada, it means 
"family of types."  Specifically, it means "family of tagged types, having 
this common ancestor."

You said above "proper idiom for a class," but it's not clear whether you 
just mean "type," or whether you mean "class" (as in "family of types").  If 
you just mean "type," then say so.

It certainly doesn't help anyone that you named the package 
AD_Converter_Class.  In fact it's horribly confusing.  Please use Ada terms, 
or I won't understand you.  Don't say "class" if you mean "type."

Secondly, you haven't explained why your AD_Converter type is tagged, or why 
it's non-limited.  (What does assignment of AD_Converter objects even 
mean???)

Please give me a reason why this type is tagged, and if it's tagged then 
please tell me about its descendents.



> What is the preferred Ada idiom for something like this?

I showed you the proper idiom.  What's the problem?

Re: Idiom for a class and an object in Ada

[Dmitry A. Kazakov]

On Tue, 19 Oct 2004 10:44:04 -0400, Matthew Heaney wrote:

> The term "class" in Ada has a very specific meaning.  In Ada, it means 
> "family of types."  Specifically, it means "family of tagged types, having 
> this common ancestor."

This is incorrect. For example ARM 12.5 refers classes of types other than
"class rooted in".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:138j4nfhzsc45$.1581kzqfi5e89$.dlg@40tude.net...
> On Tue, 19 Oct 2004 10:44:04 -0400, Matthew Heaney wrote:
>
>> The term "class" in Ada has a very specific meaning.  In Ada, it means
>> "family of types."  Specifically, it means "family of tagged types, 
>> having
>> this common ancestor."
>
> This is incorrect. For example ARM 12.5 refers classes of types other than
> "class rooted in".

Yes, of course it does, but that's obviously not what we're discussing here, 
since the OP isn't using the term "class" in the sense of "class of integer 
types," etc.

We simply need to clarify whether we're talking about a specific type T, or 
a family of types rooted at T, namely T'Class.

Re: Idiom for a class and an object in Ada

[Dmitry A. Kazakov]

On Tue, 19 Oct 2004 11:40:08 -0400, Matthew Heaney wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:138j4nfhzsc45$.1581kzqfi5e89$.dlg@40tude.net...
>> On Tue, 19 Oct 2004 10:44:04 -0400, Matthew Heaney wrote:
>>
>>> The term "class" in Ada has a very specific meaning.  In Ada, it means
>>> "family of types."  Specifically, it means "family of tagged types, 
>>> having
>>> this common ancestor."
>>
>> This is incorrect. For example ARM 12.5 refers classes of types other than
>> "class rooted in".
> 
> Yes, of course it does, but that's obviously not what we're discussing here, 
> since the OP isn't using the term "class" in the sense of "class of integer 
> types," etc.
> 
> We simply need to clarify whether we're talking about a specific type T, or 
> a family of types rooted at T, namely T'Class.

[ BTW, to be even more pedantic (:-)), T'Class is not a family of types. It
is *a* type, which is a closure of that family. ]

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.

But the original question was how to name the ultimate instances of that
type or types of a family, including generic case, sets of derived types,
constrained subtypes, whatsoever. The idiom should not depend on where the
instances come from. So important is only (if I correctly understood
Marin):

1. Instances are statically known
2. Instances should be public
3. Instances should have unique names (no arrays of, no containers of, no
factories of)

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Idiom for a class and an object in Ada

[Marin David Condic]

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

Re: Idiom for a class and an object in Ada

[Dmitry A. Kazakov]

On Wed, 20 Oct 2004 12:31:48 GMT, Marin David Condic wrote:

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

Maybe I am preaching heresy, but I find Ada's type/operation/package view
more usable than class/attribute/method. So I don't much care what would be
an OO-ish class in Ada. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message 
news:UUsdd.3499$ta5.1160@newsread3.news.atl.earthlink.net...
>
> 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.

You still haven't explained why TYPE Blivet is tagged and nonlimited.


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

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.

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.

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):

package Blivets is
   type Blivet (<>) is limited private;
   procedure Op (B : Blivet);

   function My_Blivet return Blivet;
private
   type Rep_Type is <whatever>;

   type Blivet is access all Rep_Type;
   for Blivet'Storage_Size use 0;

end Blivets;

package body Blivets is
   ...
   My_Blivet_Object : aliased Rep_Type;

   function My_Blivet return Blivet is
   begin
      return My_Blivet_Object'Access;
   end;
end Blivets;

This has the benefit that objects are allocated statically, and all uses of 
pointers are hidden from the user.

Yet another possibility is to expose the access type, but pass the object as 
an access parameter:

package Blivets is
   type Blivet (<>) is limited private;
   procedure Op (B : access Blivet);

   type Blivet_Access is access all Blivet;
   for Blivet_Access'Storage_Size use 0;

   My_Blivet : constant Blivet_Access;
private
   type Blivet is limited record ... end record;

   My_Blivet_Object : aliased Blivet;
   My_Blivet : constant Blivet_Access := My_Blivet_Object'Access;
end Blivets;


So take your pick!  In all cases, the objects are declared statically, which 
satisfies your primary constraint.

Re: Idiom for a class and an object in Ada

[Marin David Condic]

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

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"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

Re: Idiom for a class and an object in Ada

[Simon Wright]

Marin David Condic <nobody@noplace.com> writes:

> What is the preferred Ada idiom for something like this?

I'm not so hung up as Matt about people using the word class (in
conversation; I agree about use in Ada code). But I have to say,
what's wrong with Matt's suggestion? seems to answer all your needs as
stated so far ..

One thing, having "static" (I suppose you mean, created at library
level during elaboration, whatever the words are ..) can cause
elaboration order problems if the things being created are tasks. I
could say that more strongly, "are practically guaranteed to cause
elaboration order problems"! I guess this is unlikely to happen with
hardware interfaces?? Not sure if using dynamic allocation in
elaboration would help? -- probably not, need some sort of Initialize
procedure.

package body ADC is

   task type T is ...
   type T_P is access T;
   Converter_1 : T_P;

begin

   Converter_1 := new T (...);

end ADC;

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

Simon Wright <simon@pushface.org> writes:

> I'm not so hung up as Matt about people using the word class (in
> conversation; I agree about use in Ada code). But I have to say,
> what's wrong with Matt's suggestion? seems to answer all your needs as
> stated so far ..

For reasons I can't fathom, many Ada95 developers still have a very
Ada83 mindset.

This is the canonical idiom in C++ for controlling instance creation:

class C {
public:

   static C* make( /* ... */ );
   static void free(C*);

   void f(); //whatever

private:

   C();
   C(const C&);

   ~C();

   C& operator=(const C&);
};

Here, the ctor (and dtor) is declared as private, so the only way to
make a C object is by calling factory function C::make().

This has a direct translation into Ada95:

package P is

   type T (<>) is limited private;

   procedure Op (O : in out T);

   type T_Access is access all T;

   function New_T (...) return T_Access;

private

   type T is limited record ...;

end P;


Here the package provides a factory function to dynamically create
instances (or possibly return a pointer to statically declared objects,
a la the Flyweight Pattern).

Functions in Ada95 return constant objects.  (In Ada83, functions
returned values.)  Types whose full view is limited are passed by
reference.  These two facts mean you can write the equivalent of a const
reference in C++:

   const C& f();

by using a function whose return type is limited:

package P is

   type T (<>) is limited private;

   procedure Op (O : in T);

   function Object1 return T;
   function Object2 return T;

private

   type T is limited record ...;

end P;


This is exactly how Text_IO works.  The objects returned by functions
Standard_Input, Standard_Output, etc, correspond to the functions
Object1 and Object2 above.

This is the canonical Ada95 idiom for controlling instance creation, and
for declaring well-known objects.

Re: Idiom for a class and an object in Ada

[Dmitry A. Kazakov]

On Wed, 20 Oct 2004 07:24:31 GMT, Matthew Heaney wrote:

> For reasons I can't fathom, many Ada95 developers still have a very
> Ada83 mindset.

Probably because Ada 83 was good! (:-)) 

> package P is
> 
>    type T (<>) is limited private;
> 
>    procedure Op (O : in T);
> 
>    function Object1 return T;
>    function Object2 return T;
> 
> private
> 
>    type T is limited record ...;
> 
> end P;

This approach is difficult to follow with read-write objects, because it
then forces to use indirection.

> This is exactly how Text_IO works.  The objects returned by functions
> Standard_Input, Standard_Output, etc, correspond to the functions
> Object1 and Object2 above.

Yes and the price is heavy:

   procedure Put(File : in File_Type; Item : in Character); 

writes into *in* File! Even if File_Type is considered to be an "iterator",
"access window" etc, rather than the file, then definitely Put and Get
should *change* it. So what is File_Type? It is a language construct to
provide a work-around for the pattern above, i.e. a hack. A bit watery for
an IDIOM.

> This is the canonical Ada95 idiom for controlling instance creation, and
> for declaring well-known objects.

Yes, but it lacks an ability to create non-constant objects on the stack,
and it requires an extra indirection level. There should be a way for
forward object declarations.

   type X (<>) is limited private;
   A : X renames private; -- Forward rename
or so
   A : X := private; -- Forward initialization
or
   A : private X;
private
   type X is record
      Field : Integer;
   end record;
   A : X := (Field => 123); 

Then of course there should be a way for in-place modification of the
result for by-reference types and copy-out/copy-in for all others.
Anonymous access results are good, but I'd prefer a more elaborated
solution without access types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Idiom for a class and an object in Ada

[Jeffrey Carter]

Matthew Heaney wrote:

> For reasons I can't fathom, many Ada95 developers still have a very
> Ada83 mindset.

That's because Ada 83 was a very good language, and the idioms that were 
good for it are still good.

> This is the canonical idiom in C++ for controlling instance creation:
> 
> class C {
> public:
> 
>    static C* make( /* ... */ );
>    static void free(C*);
> 
>    void f(); //whatever
> 
> private:
> 
>    C();
>    C(const C&);
> 
>    ~C();
> 
>    C& operator=(const C&);
> };
> 
> Here, the ctor (and dtor) is declared as private, so the only way to
> make a C object is by calling factory function C::make().
> 
> This has a direct translation into Ada95:
> 
> package P is
> 
>    type T (<>) is limited private;
> 
>    procedure Op (O : in out T);
> 
>    type T_Access is access all T;
> 
>    function New_T (...) return T_Access;

And this is why C++ is never a good guide to how to do things in Ada. 
The pointer may well be needed in C++; it's not needed in Ada.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

Jeffrey Carter <spam@spam.com> writes:

> Matthew Heaney wrote:
> 
> > For reasons I can't fathom, many Ada95 developers still have a very
> > Ada83 mindset.
> 
> That's because Ada 83 was a very good language, and the idioms that were
> good for it are still good.

Ancient history.


> And this is why C++ is never a good guide to how to do things in
> Ada. The pointer may well be needed in C++; it's not needed in Ada.

I don't understand this comment.  How else do you dynamically create
instances of T?

Re: Idiom for a class and an object in Ada

[Dmitry A. Kazakov]

On Thu, 21 Oct 2004 01:46:39 GMT, Matthew Heaney wrote:

> Jeffrey Carter <spam@spam.com> writes:

>> And this is why C++ is never a good guide to how to do things in
>> Ada. The pointer may well be needed in C++; it's not needed in Ada.
> 
> I don't understand this comment.  How else do you dynamically create
> instances of T?

Why should they be created dynamically (heap)? Heap vs. stack is a matter
of object's scope. It should have little or no impact on the design of the
type. If it has then probably because of language deficiency, as in C++,
or, yes, in Ada where there was no way to initialize limited objects. That
will be corrected soon, I hope.

For Marin's case the objects are not dynamic. So if read-only objects would
suffice, one can just use functions returning limited objects:

package Limited_Object is
   type X (<>) is limited private;
   function O1 return X; -- No pointer needed
   ...

package body Limited_Object is
   O1_Value : X;
   function O1 return X is
   begin
      return O1_Value; -- This is OK, O1_Value is never out of scope
   end O1;
   ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 21 Oct 2004 01:46:39 GMT, Matthew Heaney wrote:
> 
> > I don't understand this comment.  How else do you dynamically create
> > instances of T?
> 
> Why should they be created dynamically (heap)? Heap vs. stack is a
> matter of object's scope. It should have little or no impact on the
> design of the type. If it has then probably because of language
> deficiency, as in C++, or, yes, in Ada where there was no way to
> initialize limited objects. That will be corrected soon, I hope.


My point was that there is *no* difference between Ada95 and C++ here.
My reasons for writing the code as I did (that is, writing a factory
function that returns a pointer) had nothing to do with language.



> For Marin's case the objects are not dynamic. So if read-only objects
> would suffice, one can just use functions returning limited objects:

Finally, someone else sees the light...

Re: Idiom for a class and an object in Ada

[Dmitry A. Kazakov]

On Thu, 21 Oct 2004 12:45:09 GMT, Matthew Heaney wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Thu, 21 Oct 2004 01:46:39 GMT, Matthew Heaney wrote:
>> 
>>> I don't understand this comment.  How else do you dynamically create
>>> instances of T?
>> 
>> Why should they be created dynamically (heap)? Heap vs. stack is a
>> matter of object's scope. It should have little or no impact on the
>> design of the type. If it has then probably because of language
>> deficiency, as in C++, or, yes, in Ada where there was no way to
>> initialize limited objects. That will be corrected soon, I hope.
> 
> My point was that there is *no* difference between Ada95 and C++ here.
> My reasons for writing the code as I did (that is, writing a factory
> function that returns a pointer) had nothing to do with language.

I see it different:

1. Why there should be a factory function?
2. Why that should return a pointer?

The reasons for 1 could be:

1.a. There are construction parameters [not the case]
1.b. The result is polymorphic [not the case]
1.c. The language does not provide default object construction [not the
case]
1.d. Renaming/aliasing, abstracting from variables [might be, but what's
the gain?]

The reasons for 2 could be:

2.a. The scope of the objects is dynamic and "new" does not fit [not the
case]
2.b. The language has problems with construction on the stack. [might well
be, if objects are limited]

If we consider all that we will see that it is rather a language problem,
that forces us to use pointers.

>> For Marin's case the objects are not dynamic. So if read-only objects
>> would suffice, one can just use functions returning limited objects:
> 
> Finally, someone else sees the light...

But if that is the case, then constants would do the trick. You need no
function for that. Initialization is an independent issue. Function
returning object is *not* a constructor, it could simulate one, but what
for if the language supports construction?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Idiom for a class and an object in Ada

[Jeffrey Carter]

Matthew Heaney wrote:

> Jeffrey Carter <spam@spam.com> writes:
> 
>>That's because Ada 83 was a very good language, and the idioms that were
>>good for it are still good.
> 
> Ancient history.

What a meaningful reply. Obviously Heany has no valid refutation.

> I don't understand this comment.  How else do you dynamically create
> instances of T?

Ignoring the absence of any requirement that the objects be created 
dynamically, there are several ways:

declare
    Instance : T renames Make (...);
begin
    ...

and

procedure Process (Object : in out T);

...

Process (Object => Make (...) );

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail
02

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

Jeffrey Carter <spam@spam.com> writes:

> Ignoring the absence of any requirement that the objects be created
> dynamically, there are several ways:
> 
> declare
>     Instance : T renames Make (...);
> begin


We appear to be comparing apples and oranges.  The technique you show
above will only work (assuming the full of the type is limited) if the
object is allocated statically.  You obviously cannot use a function to
return an object whose type is limited (the full view, anyway), if the
object is dynamically allocated on the stack.  (Try it and see.)

My example was only intended to illustrate the technique of using a
factory function to allocate instances.  The indirection allows the
package to hide the decision about whether instances are allocated
statically (e.g. the flyweight pattern) or dynamically.

-Matt

BTW: It's H-E-A-N-E-Y, like the poet.

Re: Idiom for a class and an object in Ada

[Kevin Cline]

Jeffrey Carter <spam@spam.com> wrote in message news:<woEdd.2702$%h1.1164@newsread3.news.pas.earthlink.net>...
> Matthew Heaney wrote:
> 
> > For reasons I can't fathom, many Ada95 developers still have a very
> > Ada83 mindset.
> 
> That's because Ada 83 was a very good language, and the idioms that were 
> good for it are still good.
> 
> > This is the canonical idiom in C++ for controlling instance creation:
> > 
> > class C {
> > public:
> > 
> >    static C* make( /* ... */ );
> >    static void free(C*);
> > 
> >    void f(); //whatever
> > 
> > private:
> > 
> >    C();
> >    C(const C&);
> > 
> >    ~C();
> > 
> >    C& operator=(const C&);
> > };
> > 
> > Here, the ctor (and dtor) is declared as private, so the only way to
> > make a C object is by calling factory function C::make().
> > 
> > This has a direct translation into Ada95:
> > 
> > package P is
> > 
> >    type T (<>) is limited private;
> > 
> >    procedure Op (O : in out T);
> > 
> >    type T_Access is access all T;
> > 
> >    function New_T (...) return T_Access;
> 
> And this is why C++ is never a good guide to how to do things in Ada. 
> The pointer may well be needed in C++;

Not in this case.

  class AD_Converter
  {
  private:

    AD_Converter(int line) {}
  public:
    static AD_Converter Noise;
  };

  AD_Converter AD_Converter::Noise(17);

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message 
news:e749549b.0410211131.6505da@posting.google.com...
>
>  class AD_Converter
>  {
>  private:
>
>    AD_Converter(int line) {}
>  public:
>    static AD_Converter Noise;
>  };
>
>  AD_Converter AD_Converter::Noise(17);

Yes, indeed.  I should have made this more clear.

Actually, directly translating the C++ code above to Ada is a little tricky, 
since you can't declare object Noise until the full view of the type has 
been declared.

That's what motivated my use of a selector-style function to return a 
(constant) reference to the object declared in the body (or in the private 
part of the spec).  But the real issue is that a function returns a constant 
reference, so if you want to be able to use an operation to actually modify 
the object you need to do something else.

One way is to use the Rosen Trick:

package AD_Converts is
   type AD_Converter (<>) is limited private;
   procedure Op (ADC : AD_Converter);  --modifier

   function Noise return AD_Converter;
private
   type Handle (ADC : access AD_Converter) is limited null record;
   type AD_Converter is limited record
      H : Handle (ADC'Access);
   end record;
end;

package body AD_Converters is
   procedure Op (ADC : AD_Converter) is
      X : AD_Converter renames ADC.H.ADC.all;
   begin
      ... -- modify X as desired
   end;
...
end AD_Converters;

Part of the problem is that we were given a requirement that we can't use 
access types.  If we didn't have that requirement, then you do this:

package AD_Converter is
   type AD_Converter (<>) is limited private;
   procedure Modifier (ADC : access AD_Converter);
   procedure Selector (ADC : access constant AD_Converter);

   type ADC_Access is access all AD_Converter;
   for ADC_Access'Storage_Size use 0;

   Noise : constant ADC_Access;
private
   type AD_Converter is limited record ... end record;
   --no more Rosen Trick (sorry, Jean-Pierre...)

   Noise_ADC : aliased AD_Conveter;
   Noise : constant ADC_Access := Noise_ADC'Access;
end;


However, all we're really doing is using the AD_Converter type as a fancy 
way to identify a statically declared object.  We have simpler ways of doing 
that, especially if the "object" is just an array component:

package AD_Converters is
   type AD_Converter (<>) is limited private;
   procedure Modifier (ADC : in out AD_Converter);
   procedure Selector (ADC : in AD_Converter);

   Noise : constant AD_Converter;
private
   type AD_Converter is new Positive;
   Noise : constant AD_Converter := 1;
end;

package body AD_Converters is
   type Rep_Type is limited record ... end record;
   Objects : array (AC_Converter range 1 .. <whatever>) of Rep_Type;

   procedure Modify (ADC : in out AD_Converter) is
      Object : Rep_Type renames Objects (ADC);
   begin
       ...
   end;
...
end;

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Matthew Heaney" <mheaney@on2.com> writes:

> "Kevin Cline" <kevin.cline@gmail.com> wrote in message 
> news:e749549b.0410211131.6505da@posting.google.com...
> >
> >  class AD_Converter
> >  {
> >  private:
> >
> >    AD_Converter(int line) {}
> >  public:
> >    static AD_Converter Noise;
> >  };
> >
> >  AD_Converter AD_Converter::Noise(17);
> 
> Yes, indeed.  I should have made this more clear.
> 
> Actually, directly translating the C++ code above to Ada is a little
> tricky, since you can't declare object Noise until the full view of
> the type has been declared.

I realized on my drive home that I forgot this one:

package AD_Converters is
   type AD_Converter (<>) is limited private;
   procedure Op (ADC : AD_Converter);

   Noise : constant AD_Converter;
private
   type Rep_Type is limited record ... end record;

   type AD_Converter is access all Rep_Type;
   for AD_Converter'Storage_Size use 0;

   Noise_Object : aliased Rep_Type;
   Noise : constant AD_Converter := Noise_Object'Access;
end AD_Converters;

Re: Idiom for a class and an object in Ada

[Martin Dowie]

Matthew Heaney wrote:
> For reasons I can't fathom, many Ada95 developers still have a very
> Ada83 mindset.

The reasons for this are numerous - e.g. some of us still work with Ada83
projects on a daily basis, development processes for Ada95 projects may have
been inherited with little or no change from previous projects. Changing
implementation techniques to make to 'best use' of a language would also
impact on the process and procedures for the design phase. Where a process
is already in place and not obviously failing there may be little impitous,
time or money to re-write these processes. Sometimes design processes are
shared between projects working with different implementation languages -
how do you do 'indefinite' in 'C'?..

I work for a CMM Level 5 company, so our processes are always undergoing
improvement but this sort of change is much lower in the priority list than
getting processing in place to get the best from our UML/CM/Change Control
systems.

It generally isn't out of dogma or badness or not wanting to do the 'right
thing'.

-- Martin

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message 
news:x7v4qkqrlr1.fsf@smaug.pushface.org...
>
> package body ADC is
>
>   task type T is ...
>   type T_P is access T;
>   Converter_1 : T_P;
>
> begin
>
>   Converter_1 := new T (...);
>
> end ADC;

This doesn't buy you anything.  The rule is that the "task object" 
elaborates in linear order (the same as for any other declaration), but then 
the "task" itself "activates" when the begin statement is reached.

We can write your example as:

package body ADC is
   task type T;

   O : T;  -- this is the "task object"

   task body T is ... end;

end;

No explicit allocation is necessary.  Task object O elaborates in the normal 
way, and its associated task activates at the completion of elaboration of 
the package body.

The distinction between "task object" and "task", and between "elaboration" 
and "activation", is somewhat subtle.

Re: Idiom for a class and an object in Ada

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:x7v4qkqrlr1.fsf@smaug.pushface.org...
> >
> > package body ADC is
> >
> >   task type T is ...
> >   type T_P is access T;
> >   Converter_1 : T_P;
> >
> > begin
> >
> >   Converter_1 := new T (...);
> >
> > end ADC;
> 
> This doesn't buy you anything.  The rule is that the "task object" 
> elaborates in linear order (the same as for any other declaration), but then 
> the "task" itself "activates" when the begin statement is reached.
> 
> We can write your example as:
> 
> package body ADC is
>    task type T;
> 
>    O : T;  -- this is the "task object"
> 
>    task body T is ... end;
> 
> end;
> 
> No explicit allocation is necessary.  Task object O elaborates in the normal 
> way, and its associated task activates at the completion of elaboration of 
> the package body.

And this is exactly why you end up with elaboration order problems!

package A is
   procedure P;
end A;
with B;
package body A is
   procedure P is
   begin
      null;
   end P;
end A;
package B is
   procedure Q;
end B;
with A;
package body B is
   task type T is
      entry Start;
   end T;
   O : T;
   task body T is
   begin
      accept Start;
      A.P;
   end T;
   procedure Q is
   begin
      null;
   end Q;
end B;
with A;
procedure M is
begin
   null;
end M;

smaug.pushface.org[7]$ gnatmake m
gcc -c m.adb
gcc -c a.adb
gcc -c b.adb
gnatbind -x m.ali
error: elaboration circularity detected
info:    "b (body)" must be elaborated before "b (body)"
info:       reason: implicit Elaborate_All in unit "b (body)"
info:       recompile "b (body)" with -gnatwl for full details
info:          "b (body)"
info:             must be elaborated along with its spec:
info:          "b (spec)"
info:             which is withed by:
info:          "a (body)"
info:             which must be elaborated along with its spec:
info:          "a (spec)"
info:             which is withed by:
info:          "b (body)"

gnatmake: *** bind failed.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message 
news:x7voeixb2pl.fsf@smaug.pushface.org...
>
> And this is exactly why you end up with elaboration order problems!
>
> with A;
> package body B is ...;

This needs to say:

with A;
pragma Elaborate (A);
package body B is ...;

And now all is well.

The problem is that without the pragma, your compile assumes Elaborate_All. 
But this is too strong, since A has a dependency on B.  By explicitly using 
pragma Elaborate, this only elaborates package A.

The elaboration order is thus:

A spec
B spec
A body
B body

This is one of those few times when you need Elaborate, not Elaborate_All.

Re: Idiom for a class and an object in Ada

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> This is one of those few times when you need Elaborate, not
> Elaborate_All.

I suppose (as a GNAT user) I see having to mention Elaborate at all as
being a problem!

I'm sure I've seen cases where no amount of fiddling helped ... but I
can't find them now, so better leave it.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Idiom for a class and an object in Ada

[Jeffrey Carter]

Matthew Heaney wrote:

> Too much code bloat.  There's no reason AD_Converter needs to be a
> generic, if the objects of that type are known apriori:

Perhaps. The Ada idiom for a singleton is package-as-object; the obvious 
extension from "single" to "a few" is a generic package. However, a 
discriminated type such as you described may well be a viable 
alternative. It's the idea that you need a family of tagged types, type 
extension, and all that entails for something this simple.

I would expect, in any case, that these things are the low-level 
interface to the devices, and that the application would use 
higher-level interfaces that map the range of values the device deals 
with to information meaningful to the application.

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus
53

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

Jeffrey Carter <spam@spam.com> writes:

> The Ada idiom for a singleton is package-as-object; the obvious
> extension from "single" to "a few" is a generic package.

That might have been true in Ada83, but it is not true in Ada95.

The intended Ada95 mechanism for controlling instance creation is to
declare the type as limited and indefinite, and for the package to
provide a factory function to create instances of the type.


> However, a discriminated type such as you described may well be a
> viable alternative. It's the idea that you need a family of tagged
> types, type extension, and all that entails for something this simple.

The original problem had to do with where and how to declare well-known
objects.  That problem is orthogonal to the need for type extension and
dynamic binding.

If you don't need type extension or dynamic binding, then clearly the
type doesn't need to be tagged.  See the genealogy directories in
ai302/examples at the tigris site for some examples.

Actually, I realized after I had written genealogy2 that I should have
implemented the parser like this:

package Parser is

   type Data_Type (<>) is limited private;

   function Student (Data : Data_Type) return String;
   function Advisor (Data : Data_Type) return String;
   ...

   procedure Iterate
     (Process : not null access procedure (Data : Data_Type));

...
end Parser;

Here's a case where the instances are created by the package on-the-fly,
as the passive iteration occurs.

None of the types declared in Data_Maps or Relation_Maps are tagged, but
they are all limited and indefinite.

Re: Idiom for a class and an object in Ada

[Marin David Condic]

In my particular example, I have outlawed the use of access types. It 
doesn't matter why. You can get a perfectly good static allocation of 
exactly what is needed with the plain vanilla object declaration ala:

Some_Object : Class_Package.Tagged_Record_Type ;

I don't find a problem with that. It is simple and enables me to get 
exactly what I need from the compiler, linker and other tools down the 
chain. The question is "Where do you put it?"

Dimitri seems to like a child package under the "class" package. I've 
used that in the past. It works fine, but does proliferate packages. 
There might be some variations on that (one "object" per child package 
versus all "objects" in one child package?) There are other spots to 
declare such entities and I'm wondering what is preferred by most Ada 
people who actually declare some static (library level) 'objects'?

MDC

Matthew Heaney wrote:

> 
> The intended Ada95 mechanism for controlling instance creation is to
> declare the type as limited and indefinite, and for the package to
> provide a factory function to create instances of the type.

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

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

Marin David Condic <nobody@noplace.com> writes:

> In my particular example, I have outlawed the use of access types. It
> doesn't matter why. You can get a perfectly good static allocation of
> exactly what is needed with the plain vanilla object declaration ala:
> 
> Some_Object : Class_Package.Tagged_Record_Type ;

I technique I have described doesn't require access types.  If the type
is limited, then it gets passed by reference, so you don't need an
explicit access type.

You still haven't explained why your type above is tagged, or why it is
nonlimited.

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message 
news:P2tdd.3504$ta5.1130@newsread3.news.atl.earthlink.net...
>
> In my particular example, I have outlawed the use of access types. It 
> doesn't matter why.

If you want to outlaw dynamic allocation, that's one thing.  But if you want 
to outlaw access types, that's another thing.

I showed in an earlier post how to use access types, but hide the fact that 
access types are used:

package P is
   type T (<>) is limited private;
   procedure Op (O : in T);
   function O1 return T;
   function O2 return T;
private
   type Rep_Type is limited ... end record;

   type T is access all Rep_Type;
   for T'Storage_Size use 0;
end P;

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Matthew Heaney" <mheaney@on2.com> writes:

> I showed in an earlier post how to use access types, but hide the fact
> that access types are used:
> 
> package P is
>    type T (<>) is limited private;
>    procedure Op (O : in T);
>    function O1 return T;
>    function O2 return T;
> private
>    type Rep_Type is limited ... end record;
> 
>    type T is access all Rep_Type;
>    for T'Storage_Size use 0;
> end P;


Actually, I forgot to mention that you don't need an access type if you
use an array to hold the objects:


package P is
   type T (<>) is limited private;
   procedure Op (O : in T);
   function O1 return T;
   function O2 return T;
private
   type T is range 1 .. 2;
end P;


package body P is

   type Rep_Type is limited record ... end record;

   Objects : Rep_Type (T);

   procedure Op (O : in T) is
      OO : Rep_Type renames Objects (O);
   begin
      ...
   end;

   function O1 return T is
   begin
      return 1;
   end;

   function O2 return T is
   begin
      return 2;
   end;

end P;


In fact, you don't need the private type at all:

package P is
   type T is (O1, O2);
   procedure Op (O : in T);
end P;

package body P is

   type Rep_Type is limited record ... end record;

   Objects : Rep_Type (T);

   procedure Op (O : in T) is
      OO : Rep_Type renames Objects (O);
   begin
      ...
   end;

end P;

Re: Idiom for a class and an object in Ada

[Marin David Condic]

Well, that's one approach. I'd prefer to avoid the code bloat of a 
generic when all I really need to duplicate is the data. Also, its 
tougher to do any sort of inheritance going the generic route. I'm 
wondering specifically about the usual OOD idiom of making a class out 
of a package with a tagged record - such that it can be extended with 
another child class - and where is the "best" place to declare objects 
of that class?

MDC

Marius Amado Alves 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?
> 
> 
> 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!
> 

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

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:M3Ocd.237$5i5.72@newsread2.news.atl.earthlink.net...
> 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 for example the packages Data_Maps and Relation_Maps in the genealogy
examples in the ai302 examples subdirectory:

<http://charles.tigris.org/source/browse/charles/src/ai302/examples/genealog
y/>

The idea is to create a limited private type with an unknown discriminant:

package Data_Maps is
   type Map (<>) is limited private;
  ... -- operations here

   function Dates return Map;
   function Places return Map;
private
   ... -- see code for implementation
end;

This is similar to how Standard_Input, Standard_Output, etc are implemented
in Text_IO.

Re: Idiom for a class and an object in Ada

[Martin Dowie]

> Does anybody have an opinion or experience with doing this? I know
> what I've done in the past, but I'm curious if there is any preferred
> method or idiom for this in the OO paradigm as applied to Ada?

I tend to use Ward-Mellor RTSA/OOD as a method which leaves me with a number 
of "project specific" processes on static data. But the data type also leads 
to project specific classes (or ADT) which may be based on more general 
classes (e.g. containers). e.g.

package General_Classes is  -- Most re-usable
   type Class is private;
end General_Classes;

with General_Classes;
package Project_Classes is  -- Less re-usable
   type Class is private;
   procedure Process_1 (C : in out Class);
   procedure Process_2 (C : in out Class; I : Integer);
private
   type Class is new General_Classes.Class with ...;
end Project_Classes;

package Project_Objects is  -- Least re-usable
   procedure Process_1;  -- Each process maps to a RTSA process (or a UML 
use-case)
   procedure Process_2;
end Project_Objects;

with Project_Classes;
package body Project_Objects is
   Objects : Project_Classes.Class;  -- Safely hidden data...
   procedure Process_1 is ...
   procedure Process_2 is ...
end Project_Objects;

It maps requirements to design to code very well.

$0.02

-- Martin



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004 

Re: Idiom for a class and an object in Ada

[Marin David Condic]

Interesting, but I think it misses my question. In your first package: 
General_Classes - if you had 5 specific objects of type Class and they 
are totally static (something that exists from the moment you hit the 
first instruction to the moment the power goes down and you *really* 
need them to be in global memory) - where would you declare the five 
objects of type "Class" as you've defined it?

How to do it is simple:

Object_1 : General_Classes.Class ;
Object_2 : General_Classes.Class ;
Object_3 : General_Classes.Class ;
Object_4 : General_Classes.Class ;
Object_5 : General_Classes.Class ;

In what context would you put those objects?

MDC


Martin Dowie wrote:

>>Does anybody have an opinion or experience with doing this? I know
>>what I've done in the past, but I'm curious if there is any preferred
>>method or idiom for this in the OO paradigm as applied to Ada?
> 
> 
> I tend to use Ward-Mellor RTSA/OOD as a method which leaves me with a number 
> of "project specific" processes on static data. But the data type also leads 
> to project specific classes (or ADT) which may be based on more general 
> classes (e.g. containers). e.g.
> 
> package General_Classes is  -- Most re-usable
>    type Class is private;
> end General_Classes;
> 
> with General_Classes;
> package Project_Classes is  -- Less re-usable
>    type Class is private;
>    procedure Process_1 (C : in out Class);
>    procedure Process_2 (C : in out Class; I : Integer);
> private
>    type Class is new General_Classes.Class with ...;
> end Project_Classes;
> 
> package Project_Objects is  -- Least re-usable
>    procedure Process_1;  -- Each process maps to a RTSA process (or a UML 
> use-case)
>    procedure Process_2;
> end Project_Objects;
> 
> with Project_Classes;
> package body Project_Objects is
>    Objects : Project_Classes.Class;  -- Safely hidden data...
>    procedure Process_1 is ...
>    procedure Process_2 is ...
> end Project_Objects;
> 
> It maps requirements to design to code very well.
> 
> $0.02
> 
> -- Martin
> 
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004 
> 
> 

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

Re: Idiom for a class and an object in Ada

[Martin Dowie]

Marin David Condic wrote:
> Interesting, but I think it misses my question. In your first package:
> General_Classes - if you had 5 specific objects of type Class and they
> are totally static (something that exists from the moment you hit the
> first instruction to the moment the power goes down and you *really*
> need them to be in global memory) - where would you declare the five
> objects of type "Class" as you've defined it?
>
> How to do it is simple:
>
> Object_1 : General_Classes.Class ;
> Object_2 : General_Classes.Class ;
> Object_3 : General_Classes.Class ;
> Object_4 : General_Classes.Class ;
> Object_5 : General_Classes.Class ;
>
> In what context would you put those objects?

Inside a package body with access routines. These routines tend to be the 
project-specific ones. They /may/ be portable to other systems but are less 
likely to be portable than a class that models the behaviour of those types 
of registers. But in your 5 A-D examples, and assuming that the 5 A-D were 
on a particular device, I would consider make the package name the device 
name.

If there was some issue with having to assign the registers into a 
processors particular area of memory that couldn't be done via an address 
clause but could only be done via a compiler/linker command, then I have 
separated out the data items into their own package spec - to avoid the 
access routines also being mapped into that area. The package names were 
suffixed "_GD" (for Global Data) and the coding rules were that only the 
package without the "_GD" could 'with' them and then only from the package 
body.

-- Martin

Re: Idiom for a class and an object in Ada

[Michael Paus]

Hi Marin,

your question has triggered an interesting discussion which I found
very amusing. Before I provide my proposal for a solution of your
problem I think it is essential to first discuss what the potential
benefits of your OO approach are.

You have chosen to use a tagged type to represent your A/D converters
which I think is a wise decision but neither you nor anybody else
seems to be able to give a good reason for that (if I have not missed it :-)
and also in the way you have started you are missing an opportunity
for flexibility in your design and for really exploiting your OO approach.

First of all your A/D converter class should be abstract and in all places
where you later access an A/D converter you should only refer to this abstract
base class. This gives you the possibility to easily exchange the implementation
of your A/D converter by providing different implementations of sub-classes of
your base class. The decision of which implementation you want to use can
even be done at run-time if you like. E.g., I often use this technique to
provide one sub-class for the real hardware and one which is only linked to
a simulation device which is connected via ethernet. I think this makes the
potential benefit of the OO approach clear.

Now that the goal is clearer it is easier to find a solution for your original
question. I like to be able to put together different configurations of my
software. E.g., one that is configured to run on the target and another one
which is used for a PC based simulation of the software and I want to change
as little of the software as necessary to create a new configuration.

I therefore have a
configuration specific main program and also a configuration specific package
which only has an "Initialize" and a "Start" procedure. As this package is
configuration specific no other package is allowed to access this package.
In this package I declare all the top level and configuration specific
objects statically and if some object needs another object I pass in a
class wide access value to the corresponding object in the "Initialize"
method. Alternatively you can also provide abstract factory packages for
these objects. This is useful in cases where an instance of these objects
is used in many places of your software.

 From a reusability point of view it is important that you keep the creation
of instances separate from the objects which use them. For me this approach
has worked very well and it even has some more advantages which I have not
discussed here.

Yours

Michael

Re: Idiom for a class and an object in Ada

[Matthew Heaney]

"Michael Paus" <pausnospam@nospamib-paus.com> wrote in message 
news:cl6395$g1l$1@online.de...
>
> You have chosen to use a tagged type to represent your A/D converters
> which I think is a wise decision but neither you nor anybody else
> seems to be able to give a good reason for that (if I have not missed it 
> :-)
> and also in the way you have started you are missing an opportunity
> for flexibility in your design and for really exploiting your OO approach.

How are you able to evaluate whether the use of a tagged type is a "wise 
decision" unless you have been given reasons why the type is tagged?

My judgement about the fact that the type is tagged and nonlimited is that 
this is a very *unwise* decision.

There is no reason for the type to be tagged unless you need type extension 
or dynamic binding.

There is no reason why the global objects' type should have assignment.

There is no reason why the global objects' type should allow anyone to 
create instances anywhere.

Re: Idiom for a class and an object in Ada

[Michael Paus]

Matthew Heaney wrote:

> "Michael Paus" <pausnospam@nospamib-paus.com> wrote in message 
> news:cl6395$g1l$1@online.de...
> 
>>You have chosen to use a tagged type to represent your A/D converters
>>which I think is a wise decision but neither you nor anybody else
>>seems to be able to give a good reason for that (if I have not missed it 
>>:-)
>>and also in the way you have started you are missing an opportunity
>>for flexibility in your design and for really exploiting your OO approach.
> 
> 
> How are you able to evaluate whether the use of a tagged type is a "wise 
> decision" unless you have been given reasons why the type is tagged?

According to my experience in similar situations the use of tagged types
offers more flexibility than other approaches and I therefore think it is
a wise decision.

> My judgement about the fact that the type is tagged and nonlimited is that 
> this is a very *unwise* decision.

Your opinion without an explanation.

> There is no reason for the type to be tagged unless you need type extension 
> or dynamic binding.

I think I have explained already why you do need type extension here.

> There is no reason why the global objects' type should have assignment.

I did not say anything about assignment.

> There is no reason why the global objects' type should allow anyone to 
> create instances anywhere.

I also did not say anthing about that. You can hide that in a factory package.

Re: Idiom for a class and an object in Ada

[Marin David Condic]

I chose the A/D converter example because I needed to think of something 
that exists statically in some fixed number within a system and is 
highly unlikely to change over time. I might have gone political and 
used "Senate Seats" since there are only 50 of them and (depending on 
the application in mind) will likely be some kind of fixed objects from 
start to finish.

I'm really sorry people got wrapped around the axle of the A/D stuff 
because I was looking for a more general answer to a more general 
question about OO Programming in Ada.

That said, I thought your remarks were well thought out anyway. ;-)

MDC

Michael Paus wrote:

> You have chosen to use a tagged type to represent your A/D converters
> which I think is a wise decision but neither you nor anybody else
> seems to be able to give a good reason for that (if I have not missed it 
> :-)
> and also in the way you have started you are missing an opportunity
> for flexibility in your design and for really exploiting your OO approach.

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

Re: Idiom for a class and an object in Ada

[Stephen Leake]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> Jeffrey Carter <spam@spam.com> writes:
> 
> > Matthew Heaney wrote:
> > 
> > > For reasons I can't fathom, many Ada95 developers still have a very
> > > Ada83 mindset.
> > 
> > That's because Ada 83 was a very good language, and the idioms that were
> > good for it are still good.
> 
> Ancient history.

The mere fact that something is _ancient_ doesn't mean it's _bad_.
Here are some truly ancient facts:

2 + 2 = 4

a**2 + b**2 = c**2

F = M a

Will you dismiss those in the same way?

Please give real reasons why Ada 83 idioms are no longer useful.

--
-- Stephe

___________________________________________________________
This mail sent using ToadMail -- Web based e-mail @ ToadNet