Basic Explaination of OO in Ada

Basic Explaination of OO in Ada

[richard.charts]

I'm new to Ada, having to learn it for work, and I am beginning to
understand the language, I think.
However, coming from C (and family) and Java and other "modern"
languages, I can't seem to wrap my head around Ada's OO methods.  Is it
that there is simply nothing like a class in C++ or Java?

As a learning exercise, I'm trying to convert a simple Python program
to Ada.
The basics of the program were that it took in data about a Person
object(or Student or Advisor) and stored it into array for
manipulation.
At first, I kept trying to convert almost line for line to Ada.  But I
couldn't build the classes in the same way.
Is the correct way to think in Ada, that in a package, there is some
record "object" and also a number of subprograms that can interact
with/on that record?


Thanks.

Re: Basic Explaination of OO in Ada

[Georg Bauhaus]

On Mon, 2006-09-18 at 08:24 -0700, richard.charts@gmail.com wrote:


> Is the correct way to think in Ada, that in a package, there is some
> record "object" and also a number of subprograms that can interact
> with/on that record?

Yes, this is the "normal" approach.


Package Module is

   type T is tagged private;

   procedure put(x: in out T; item: SOME_TYPE);

   function get(x: T) return SOME_TYPE;

private

  type T is tagged record
    ... implementation details ...
  end record;

end Module;

Re: Basic Explaination of OO in Ada

[Georg Bauhaus]

On Mon, 2006-09-18 at 08:24 -0700, richard.charts@gmail.com wrote:
> I can't seem to wrap my head around Ada's OO methods.  Is it
> that there is simply nothing like a class in C++ or Java?

There is something like a class in C++ or Java, but not exactly
the same thing. (In fact, writing for the JVM in Ada is pretty
straightforward.) One difference is that you don't declare the
"class"'s operations within the class, but right next to it,
in the containing package.

Another difference is that you won't be using pointers of
references that much, because dispatching works mostly without
them.

However, you will notice that there is a 'Class attribute in
Ada. After you have some clarifying examples, you might want
to look at it.

A good book by John English is available on-line, see
http://www.it.bton.ac.uk/staff/je/adacraft/

Re: Basic Explaination of OO in Ada

[Javier Miranda]

On Sep 18, 2006, at 4:41 PM, Dennis Lee Bieber wrote:

> 	Not "object" but "type", followed immediately by the list of
> procedures/functions that work on that type. Ada95 does not use the
> "object.method(args)" syntax -- it dispatches on "method(object,  
> args)".

... but Ada 2005 has the object.method notation (and the recent public
versions of the GNAT compiler already provide such support). This  
feature
is described here:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00252.TXT?rev=1.16

My two cents ;-)

--- Javier Miranda

Re: Basic Explaination of OO in Ada

[Robert A Duff]

richard.charts@gmail.com writes:

> I'm new to Ada, having to learn it for work, and I am beginning to
> understand the language, I think.
> However, coming from C (and family) and Java and other "modern"
> languages, I can't seem to wrap my head around Ada's OO methods.  Is it
> that there is simply nothing like a class in C++ or Java?

Right.  The things you can do are roughly the same, but they look rather
different.

In Ada, packages are all about visibility, encapsulation, information
hiding, and so forth.  Tageged and class-wide types are all about type
extension and run-time polymorphism and so forth.  C++ and Java combine
all these things into one language feature -- the "class" -- whereas Ada
splits them in two.

Another unusual thing about Ada is the split between "specific type",
which represents a particular point in the type heirarchy, and
"class-wide type", which represents a whole [sub]hierarchy.

> As a learning exercise, I'm trying to convert a simple Python program
> to Ada.
> The basics of the program were that it took in data about a Person
> object(or Student or Advisor) and stored it into array for
> manipulation.
> At first, I kept trying to convert almost line for line to Ada.  But I
> couldn't build the classes in the same way.
> Is the correct way to think in Ada, that in a package, there is some
> record "object" and also a number of subprograms that can interact
> with/on that record?

Usually, for each abstraction, you have a package containing one main
type, along with primitive operations on that type.

- Bob

Re: Basic Explaination of OO in Ada

[Gautier]

richard.charts@gmail.com:

> However, coming from C (and family) and Java and other "modern"
> languages, I can't seem to wrap my head around Ada's OO methods.

Are you saying that C is more modern than Ada ?! You must be a fashion (or 
marketing) victim...
Just kidding - Gautier
______________________________________________________________
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Basic Explaination of OO in Ada

[richard.charts]

Gautier wrote:
> richard.charts@gmail.com:
>
> > However, coming from C (and family) and Java and other "modern"
> > languages, I can't seem to wrap my head around Ada's OO methods.
>
> Are you saying that C is more modern than Ada ?! You must be a fashion (or
> marketing) victim...
> Just kidding - Gautier

More Java and Python and the like.  Although you have to admit far more
students will know about C than Ada.  I pretty sure I heard it
mentioned once in my undergrad, and that was the prof in the OS class
asking if anyone had ever used it.

To the rest thanks.  I think I'm getting it now.
I found Ada Distilled today though this group and that makes the
transition a little easier.
I've been trying to use "Ada as a 2nd Language", and while it's really
indepth, it's difficult to understand if you're used to the C/Java way
of OO. IMHO.
Thank again.

Re: Basic Explaination of OO in Ada

[Lucretia]

> > Are you saying that C is more modern than Ada ?! You must be a fashion (or

Wel yes and no...

;-D

> More Java and Python and the like.  Although you have to admit far more
> students will know about C than Ada.  I pretty sure I heard it
> mentioned once in my undergrad, and that was the prof in the OS class
> asking if anyone had ever used it.

Well, I had to learn it at university and I have to say, I found it to
be really easy at uni, and only when I relearnt it later on did I find
it more difficult.

> To the rest thanks.  I think I'm getting it now.
> I found Ada Distilled today though this group and that makes the
> transition a little easier.
> I've been trying to use "Ada as a 2nd Language", and while it's really
> indepth, it's difficult to understand if you're used to the C/Java way

I was already used to the C/C++ way before I went to uni, so I'm not
too sure that's the reasoning.

Luke.

Re: Basic Explaination of OO in Ada

[gautier_niouzes]

richard.charts@gmail.com:

> > > However, coming from C (and family) and Java and other "modern"
> > > languages, I can't seem to wrap my head around Ada's OO methods.
> >
> > Are you saying that C is more modern than Ada ?! You must be a fashion (or
> > marketing) victim...
> > Just kidding - Gautier
>
> More Java and Python and the like.

OK, sounds better...

> Although you have to admit far more students will know about C than Ada.

That absolutely clear. Must be that fascination for the Sixties...
respect for the classic values.

> I pretty sure I heard it
> mentioned once in my undergrad, and that was the prof in the OS class
> asking if anyone had ever used it.

Similar for me. I essentially learned about Ada via a private
channel...
Cheers
G.

Re: Basic Explaination of OO in Ada

[adaworks]

<richard.charts@gmail.com> wrote in message 
news:1158609351.098445.226100@d34g2000cwd.googlegroups.com...
> I found Ada Distilled today though this group and that makes the
> transition a little easier.
>
I suppose this means I need to find the time to update
Ada Distilled to reflect the changes in Ada 2005.   I
had intended to do this in 2006, but just have not had
the time since I am not as directly involved with Ada
these days.

My other responsibilities have been keeping me really
busy.   I will try to get it done by Spring.   No guarantee,
though.

Richard Riehle 

Re: Basic Explaination of OO in Ada

[Marco]

"--- Javier Miranda :
.. but Ada 2005 has the object.method notation (and the recent public
versions of the GNAT compiler already provide such support). This
feature
is described here:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00252.TXT?rev=1.16
"

Are there any additional over-head / run-time costs associated with
this style syntax?

I guess for now only GNAT supports it.

Re: Basic Explaination of OO in Ada

[Javier Miranda]

On Nov 24, 2006, at 9:48 AM, Marco wrote:

> "--- Javier Miranda :
> .. but Ada 2005 has the object.method notation (and the recent public
> versions of the GNAT compiler already provide such support). This
> feature
> is described here:
>
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00252.TXT?rev=1.16
> "
>
> Are there any additional over-head / run-time costs associated with
> this style syntax?

No. There is just a minor additional overhead at compile time because
the compiler must support the old and new syntax.

> I guess for now only GNAT supports it.

I think so ;-)

--- Javier Miranda

Re: Basic Explaination of OO in Ada

[Lucretia]

Hi,

One thing that (I don't think) is really explained clearly enough is
the idea of *class-wide*. For example a class-wide type is one which
consists of every type in that hierarchy, take this hierarchy:

Shape
  + Circle
  + Polygon
     + Square
     + Triangle

If you were to say Shape'Class, this basically means any type in the
Shape hierarchy, and if you were to say Polygon'Class this means
anything in the Polygon hierarchy (but not including Shape).

Another part of the class-wide is the subprogram, a class-wide
subprogram applies to all types in that hierarchy and cannot be
overridden - it can be overloaded though:

function X(Self : Shape'Class) return Float;

This function applies to Shape, Circle, Polygon, Square, Triangle,
whereas:

function Circumference(Self : Circle'Class) return Float;

Applies onto to the hierarchy rooted at Circle (nothing below it - you
can't pass a Shape to that function).

I found this confusing because the literature isn't (IMO) clear.

Luke.

Re: Basic Explaination of OO in Ada

[Jeffrey R. Carter]

richard.charts@gmail.com wrote:
> I'm new to Ada, having to learn it for work, and I am beginning to
> understand the language, I think.
> However, coming from C (and family) and Java and other "modern"
> languages, I can't seem to wrap my head around Ada's OO methods.  Is it
> that there is simply nothing like a class in C++ or Java?

You should realize that what you're asking about is not OO, but 
programming by extension. Because "OO" became a synonym for "good", and 
early examples of OO were shown in languages that supported (or 
required) programming by extension, programming by extension got called 
OOP, but that is a misnomer.

Programming by extension does not necessarily have anything to do with 
object orientation. Programming by extension is an implementation 
technique. Object orientation is a design attribute and may be 
implemented without using programming by extension.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23

Re: Basic Explaination of OO in Ada

[Lucretia]

> You should realize that what you're asking about is not OO, but
> programming by extension. Because "OO" became a synonym for "good", and

[snip]

> object orientation. Programming by extension is an implementation
> technique. Object orientation is a design attribute and may be

This is very true and a lot of programmers don't realise they can
develop in an OO way in asm or C (or any procedural language).

Luke.

Re: Basic Explaination of OO in Ada

[richard.charts]

Lucretia wrote:
> > You should realize that what you're asking about is not OO, but
> > programming by extension. Because "OO" became a synonym for "good", and
>
> [snip]
>
> > object orientation. Programming by extension is an implementation
> > technique. Object orientation is a design attribute and may be
>
> This is very true and a lot of programmers don't realise they can
> develop in an OO way in asm or C (or any procedural language).
>
> Luke.

So basically, OO is the principles:
polymorph,
encaps,
inheritance.

And Programming by extension is the way to do it in Ada, as
class something:
{
}
would be in C++?


One thing I'm still confused on is the use of access objects
versus/with the use of object'class.
I understand using object'class for polymorphism and inheritance, but
can access objects be used in a similar manner?


As for the use of the python program.  It was just something I wrote a
week ago for a group I help with.  Since it was still fresh in my head,
it was the easiest thing to try to convert.

Re: Basic Explaination of OO in Ada

[Lucretia]

richard.charts@gmail.com wrote:
> One thing I'm still confused on is the use of access objects

An access type is equivalent to a pointer in C, although an access type
in Ada may or may not be an actual address, it could be an offset into
a block of memory.

Luke.

Re: Basic Explaination of OO in Ada

[richard.charts]

Lucretia wrote:
> richard.charts@gmail.com wrote:
> > One thing I'm still confused on is the use of access objects
>
> An access type is equivalent to a pointer in C, although an access type
> in Ada may or may not be an actual address, it could be an offset into
> a block of memory.
>
> Luke.

I understand that part, but I do not see how an access type could be
used to handle polymorphism.  Unless that is the point.

or (as I am scrolling through Ada Distilled) is it that I am
misunderstanding Storage Pool Access Type vs General Access Type?  Is
it possible to for object_type to handle either object or sub_object?

Re: Basic Explaination of OO in Ada

[Dmitry A. Kazakov]

On 19 Sep 2006 07:23:26 -0700, richard.charts@gmail.com wrote:

> Lucretia wrote:
>> richard.charts@gmail.com wrote:
>>> One thing I'm still confused on is the use of access objects
>>
>> An access type is equivalent to a pointer in C, although an access type
>> in Ada may or may not be an actual address, it could be an offset into
>> a block of memory.
>>
>> Luke.
> 
> I understand that part, but I do not see how an access type could be
> used to handle polymorphism.  Unless that is the point.

Same as objects pointers can be specific and class-wide. So:

            Specific   Class-wide (=polymorphic)
Object      T            T'Class
Pointer  access T   access T'Class

Polymorphic things, be they pointers or objects, natively support dispatch.
Therefore a dispatching subprogram (= in Ada terms "primitive") can be
defined for both.

type T is tagged ...;
procedure Foo (X : T);
procedure Bar (X : access T);

Foo and Bar are primitive. They both are defined on the class. This means
that each member of T'Class "has" Foo and each member of access T'Class
"has" Bar. Foo and Bar are said dynamically polymorphic = dispatching =
virtual in C++ terms = primitive operations in Ada terms. The
implementation of Foo and Bar consists out of many type-specific
implementations. So each type derived from T has some part of the body of
Foo. This part is either inherited from the base type or overridden.

Class-wide subprograms are also defined on the class:

procedure Foo (X : T'Class);
procedure Bar (X : access T'Class);

But they have the same body for all members of the class = they don't
dispatch (you don't need to if the body is same).

> or (as I am scrolling through Ada Distilled) is it that I am
> misunderstanding Storage Pool Access Type vs General Access Type?

General access type = the object can be in any pool. Pool access = object
can only be in a specific pool. In this sense, yes, general access pointers
dispatch on the actual pool. If the target type is polymorphic they also
dispatch on that. So access T is "double dispatching."

Ada offers all four combinations of access types regarding polymorphism
against the target type and the pool type:
                                           
                                   T        Pool
type T_Ptr is access T            specific   specific
type T_Ptr is access T'Class      class-wide specific
type T_Ptr is access all T        specific   class-wide
type T_Ptr is access all T'Class  class-wide class-wide

> Is it possible to for object_type to handle either object or sub_object?

No. It must be object_type'Class.

When S is derived from T, then T'Class can hold T and S. But T and S are
different types, and no object can be of two types at the same time.

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

Re: Basic Explaination of OO in Ada

[Ludovic Brenta]

> So basically, OO is the principles:
> polymorph,
> encaps,
> inheritance.
>
> And Programming by extension is the way to do it in Ada, as
> class something:
> {
> }
> would be in C++?

Not exactly. That construct in C++ corresponds to several of Ada's
constructs:

- a class in C++ is a unit of encapsulation, since it has public,
private and protected parts. In Ada, packages, not types, are the units
of encapsulation; they have public, body and private parts
(respectively).

- a class T in C++ corresponds to a tagged type in Ada, but it also
implicitly declares a pointer type (T*) and a reference type (T&) which
correspond to Ada's class-wide access types; thus:

class T {};

is equivalent to

package P is
   type T is tagged null record;
   type Pointer_To_T is access all T'Class;
   type Reference_To_T is access all T'Class;
end P;

Programming by extension does not necessarily involve inheritance.
Consider:

package Pak2 is
   type T is private; -- not necessarily tagged
   procedure Proc (Object : in T);
private
   type T is ...
end Pak2;

package Pak2.Extensions is
   procedure Additional_Operation (Object : in out T);
   type Extended is record
      Base : T;
      Additional_Data : ...;
   end record;
end Pak2.Extensions;

This is extension by composition, as opposed to inheritance. Of course,
you already understand how to program by extension by means of
inheritance. there are still other ways, like "mix-ins", which combines
composition and inheritance.

> One thing I'm still confused on is the use of access objects
> versus/with the use of object'class.
> I understand using object'class for polymorphism and inheritance, but
> can access objects be used in a similar manner?

I think about it this way. An object of a class-wide type is
indefinite; we do not know its size, because its specific type may be
anywhere in the inheritance tree. In contrast, an
access-to-class-wide-object has a known size (usually just that of an
address). As a consequence, you can create arrays of access values, but
not arrays of class-wide objects.

So, access types are not necessary to achieve polymorphism; the
following achieves polymorphism without an access type:

package Pak is
   type T is tagged private;
   procedure P (Object : in out T); -- primitive operation
end Pak; -- body omitted

with Pak;
procedure Test (Object : in out Pak.T'Class) is
begin
   Pak.P (Object); -- dynamic dispatch, achieves polymorphism
end Test;

Access types come in handy if you want a collection of class-wide
objects; the collection is said to be polymorphic:

with Pak;
package Collection is
   type Ref is access Pak.T'Class; -- access-to-class-wide-objects
   type Vector is array (Positive range <>) of Ref; -- polymorphic
vector
   procedure Traverse (V : in Vector);
end Collection;

package body Collection is
   procedure Traverse (V : in Vector) is
   begin
      for J in V'Range loop
         if V (J) /= null then
            Pak.P (V (J).all); -- dispatches on the specific type of
the object
         end if;
      end loop;
   end Traverse;
end Collection;

Here's another interesting tip for C++ programmers. In C++, once you
declare a member function to be "virtual", all calls to that member
function dispatch  dynamically, across the entire program. Conversely,
if a member function lacks the "virtual" keyword, calls to it are
always static. The only way you can determine whether calls dispatch
statically or dynamically is by looking at the declaration of the
member function. Things can become quite nasty if a class overrides an
inherited, non-virtual member function, and makes it virtual. I'm not
even sure what the language rules are in this case.

In contrast, in Ada, you do not declare primitive operations as
"virtual", or "dynamic" or whatever. Instead, you choose *at the point
of call* whether or not the call dispatches. Consider:

with Pak; use Pak;
procedure Test (Object : in out T'Class) is
begin
   P (Object); -- dynamic dispatch
   P (T (Object)); -- view conversion to a specific type => static
dispatch
end Test;

As consequences:
- you always know whether or not the call dispatches dynamically by
just looking at the call
- you can choose how to dispatch based on your requirements
- a primitive operation cannot be "virtual" in some contexts and
"non-virtual" in others. It is always "potentially virtual".

HTH

-- 
Ludovic Brenta.

Re: Basic Explaination of OO in Ada

[Alex R. Mosteo]

Ludovic Brenta wrote:

> Access types come in handy if you want a collection of class-wide
> objects; the collection is said to be polymorphic:
> 
> with Pak;
> package Collection is
>    type Ref is access Pak.T'Class; -- access-to-class-wide-objects
>    type Vector is array (Positive range <>) of Ref; -- polymorphic
> vector
>    procedure Traverse (V : in Vector);
> end Collection;
> 
> package body Collection is
>    procedure Traverse (V : in Vector) is
>    begin
>       for J in V'Range loop
>          if V (J) /= null then
>             Pak.P (V (J).all); -- dispatches on the specific type of
> the object
>          end if;
>       end loop;
>    end Traverse;
> end Collection;

Just a note: although what Ludovic writes is right, and you can only have
vanilla arrays of definite types, you can have more sophisticated
containers (for example Ada.Containers.Indefinite_Vectors) that store
class-wide types in Ada 2005:

package Pak_Vectors is 
  new Ada.Containers.Indefinite_Vectors (Positive, Pak.T'Class);

In this case, however, you store copies so some overhead can occur, but in
many cases it can be more convenient than starting to play with pointers.

Re: Basic Explaination of OO in Ada

[Ludovic Brenta]

Alex R. Mosteo wrote:
> Just a note: although what Ludovic writes is right, and you can only have
> vanilla arrays of definite types, you can have more sophisticated
> containers (for example Ada.Containers.Indefinite_Vectors) that store
> class-wide types in Ada 2005:
>
> package Pak_Vectors is
>   new Ada.Containers.Indefinite_Vectors (Positive, Pak.T'Class);
>
> In this case, however, you store copies so some overhead can occur, but in
> many cases it can be more convenient than starting to play with pointers.

Doesn't Ada.Containers.Indefinite_Vectors have to declare a class-wide
access type for its internal use? I'd guess so. But, it hides the
access type from the user, and that's encapsulation at its best.

In Ada, one rarely needs access types at all. The only justification
for declaring one is because you're doing some kind of dynamic data
structure and allocating dynamically on the heap. With the standard
Ada.Containers, you'd need access types even less often.

That's why in my examples I did not declare an access type along with
the tagged type (in package P); instead, I declared an access type in
another package (package Collection) because that package absolutely
needed one.

-- 
Ludovic Brenta.

Re: Basic Explaination of OO in Ada

[Alex R. Mosteo]

Ludovic Brenta wrote:

> Alex R. Mosteo wrote:
>> Just a note: although what Ludovic writes is right, and you can only have
>> vanilla arrays of definite types, you can have more sophisticated
>> containers (for example Ada.Containers.Indefinite_Vectors) that store
>> class-wide types in Ada 2005:
>>
>> package Pak_Vectors is
>>   new Ada.Containers.Indefinite_Vectors (Positive, Pak.T'Class);
>>
>> In this case, however, you store copies so some overhead can occur, but
>> in many cases it can be more convenient than starting to play with
>> pointers.
> 
> Doesn't Ada.Containers.Indefinite_Vectors have to declare a class-wide
> access type for its internal use? I'd guess so. But, it hides the
> access type from the user, and that's encapsulation at its best.

Yep, I suppose so (but I didn't looked for it).

> In Ada, one rarely needs access types at all. The only justification
> for declaring one is because you're doing some kind of dynamic data
> structure and allocating dynamically on the heap. With the standard
> Ada.Containers, you'd need access types even less often.

Agreed.

> That's why in my examples I did not declare an access type along with
> the tagged type (in package P); instead, I declared an access type in
> another package (package Collection) because that package absolutely
> needed one.

Ok, I missed your intention with the example here, so I was trying to make
clear that one shouldn't be too keen on jumping to access types :)

Re: Basic Explaination of OO in Ada

[Maciej Sobczak]

Ludovic Brenta wrote:


> Here's another interesting tip for C++ programmers. In C++, once you
> declare a member function to be "virtual", all calls to that member
> function dispatch  dynamically, across the entire program.

Except when you ask it otherwise by qualifying the function name at the 
call site, see below.

> Conversely,
> if a member function lacks the "virtual" keyword, calls to it are
> always static. The only way you can determine whether calls dispatch
> statically or dynamically is by looking at the declaration of the
> member function. Things can become quite nasty if a class overrides an
> inherited, non-virtual member function, and makes it virtual.

Yes, it becomes nasty. It's a classical no-no for C++ programmers.

> I'm not
> even sure what the language rules are in this case.

The static type used to call determines whether it dispatches or not, 
because it's the static type (of the pointer or reference) that allows 
to check whether the function is virtual.

> In contrast, in Ada, you do not declare primitive operations as
> "virtual", or "dynamic" or whatever. Instead, you choose *at the point
> of call* whether or not the call dispatches. Consider:
> 
> with Pak; use Pak;
> procedure Test (Object : in out T'Class) is
> begin
>    P (Object); -- dynamic dispatch
>    P (T (Object)); -- view conversion to a specific type => static
> dispatch
> end Test;

Similar for C++:

p->fun(); // dynamic dispatch if in *p fun is virtual
p->BaseClass::fun(); // no dynamic dispatch


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Basic Explaination of OO in Ada

[Jeffrey R. Carter]

richard.charts@gmail.com wrote:
> 
> So basically, OO is the principles:
> polymorph,
> encaps,
> inheritance.
> 
> And Programming by extension is the way to do it in Ada, as
> class something:
> {
> }
> would be in C++?

No. OO is encapsulation of data and the operations on those data. In Ada 
83, this was done through abstract state machines (package as object) or 
abstract data types ([limited] private type and corresponding 
operations). In assembler or C it's done through discipline.

Programming by extension is the use of type extension (type X is new 
Tagged_Type with ...;), also called inheritance. Dispatching (also 
called polymorphism) can also be part of this, but in Ada, much of what 
would be dispatching calls in other languages are static.

Ada also has package extension (child packages) as a form of programming 
by extension.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47

Re: Basic Explaination of OO in Ada

[Hyman Rosen]

Jeffrey R. Carter wrote:
> in Ada, much of what would be dispatching calls in other languages are static

Why? Do you have an example?

Re: Basic Explaination of OO in Ada

[Dmitry A. Kazakov]

On 19 Sep 2006 14:15:40 -0700, Hyman Rosen wrote:

> Jeffrey R. Carter wrote:
>> in Ada, much of what would be dispatching calls in other languages are static
> 
> Why? Do you have an example?

That's because of no re-dispatch in Ada.

There is no figures, but perhaps 70% of dispatching calls in C++ would
become static in an equivalent Ada program. T /= T'Class pays off!

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

Re: Basic Explaination of OO in Ada

[Martin Krischik]

richard.charts@gmail.com schrieb:

> I'm new to Ada, having to learn it for work, and I am beginning to
> understand the language, I think.

> However, coming from C (and family) and Java and other "modern"

C was invented 1973 and Ada 1983 ;-).

> languages, I can't seem to wrap my head around Ada's OO methods.  Is it
> that there is simply nothing like a class in C++ or Java?

See:

http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation


> As a learning exercise, I'm trying to convert a simple Python program
> to Ada.

Well Pythons OO is not best. I won't go into much detatil but
encapsulation virtualy does not exist.

> The basics of the program were that it took in data about a Person
> object(or Student or Advisor) and stored it into array for
> manipulation.
> At first, I kept trying to convert almost line for line to Ada.  But I
> couldn't build the classes in the same way.
> Is the correct way to think in Ada, that in a package, there is some
> record "object" and also a number of subprograms that can interact
> with/on that record?

That's about it. I allready quoted the relelvant Wikibook link - you
find a pretty good explanation there.

Martin

Re: Basic Explaination of OO in Ada

[Jeffrey R. Carter]

Martin Krischik wrote:
> 
> C was invented 1973 and Ada 1983 ;-).

MIL-STD-1815: The Ada Programming Language; 1980 Dec 10.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47

Re: Basic Explaination of OO in Ada

[Martin Krischik]

Jeffrey R. Carter schrieb:

> Martin Krischik wrote:
>
> > C was invented 1973 and Ada 1983 ;-).
>
> MIL-STD-1815: The Ada Programming Language; 1980 Dec 10.

;-) - Well that makes it 3 years for Ada to move from the it's
beginnings to ISO-Standard - and  16 years for C.

Martin

Re: Basic Explaination of OO in Ada

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1158734462.808175.277700@i3g2000cwc.googlegroups.com...
>
> Jeffrey R. Carter schrieb:
>
> > Martin Krischik wrote:
> >
> > > C was invented 1973 and Ada 1983 ;-).
> >
> > MIL-STD-1815: The Ada Programming Language; 1980 Dec 10.
>
> ;-) - Well that makes it 3 years for Ada to move from the it's
> beginnings to ISO-Standard - and  16 years for C.

Ummm, not quite. The ISO standard for Ada was approved in 1987; it was the
MIL-STD-1815A that was approved in 1983. While the content was identical, it
took 4 extra years for ISO approval.

                                Randy.