Re: ADA Objects Help!

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <3g49bu$7fv@nps.navy.mil>, swdecato@nps.navy.mil writes: 

|> I am a new Ada student, so correct me if I make any glaring mistakes.  Your
|> sample code attempts to mimic a C++ class using a package.  The problem with
|> the package implementation is that I can't instantiate instances of the object
|> at run time.

Of course you can: 

   X: C_Type;
   Y: C_Type;
   type C_Pointer_Type is access C_Type;
   Z: C_Pointer_Type := new C_Type;

(C++ confuses things enough by using the same construct, the class, both
as a type definition and a module.  Let's not make it worse by using the
term "object" as a synonym for "class".  An object is an instance of a
class.  In a language in which classes are not runtime entities--in
contrast to Smalltalk, for example--an "instance of an object" is sloppy
and misleading terminology.)

X, Y, and Z.all each contain their own copies of all data that differ
from one object to another.  All the entities that are really the same
for all objects--functions and what C++ calls static data--are declared
in the package, clearly indicating that they are per-type (or
per-package, or per-class) entities rather than per-object entities.

|>               In Ada, a pointer to a package is created at compile time since
|> the declaration using the "new" operation occurs prior to the firt BEGIN.  From
|> a syntax standpoint, Ada packages are as close to C++ classes as you can get,
|> minus the dynamic allocation.

Ada packages are not run-time entities, any more than a C header file is.
They are a mechanism for grouping logically related entities.  They are
not assigned, pointed to, or passed to subprograms.  They are not
components of arrays or records.  A package IS analogous to a class in
that both can be used as modules.  A record-type declaration is analogous
to a class in that both can contain components and have instances of
them, each of which has its own copies of each of the components.

|> Many Ada folks have demonstrated how Ada objects are created and deleted.
|> My argument against the Ada style was that I felt that the C++ syntax more
|> accurately modelled the englist language.  I have no doubt that the same effect
|> can be achieved with either language.  I still say that the following code is
|> easier to understand when dealing with objects...
|>
|>              MY_TYPE *objectPtr = new MY_TYPE;
|>                      objectPtr->run();
|>                      objectPtr->sleep();
|>              objectPtr->move();
|>              objectPtr->Set(A,B);
|>
|>              etc
|>
|> In Ada the same program would be: 
|>
|>              Run(objectPtr);
|>              Sleep(objectPtr);
|>              Move(objectPtr);
|>              Set(objectPtr, A, B);

There is a style of Ada programming that reminds you which package is the
source of the operations you are calling: 

   package Widgets is
      type Widget_Type is ...;
      type Widget_Pointer_Type is access Widget_Type;
      procedure Run (X: access Widget_Type);
      procedure Sleep (X: access Widget_Type);
      procedure Move (X: access Widget_Type);
      procedure Set (X: access Widget_Type; Y, Z: in out Who_Knows_What);
      ...
   end Widgets;

   Object_Pointer : Widgets.Widget_Pointer_Type := new Widget_Type;
   A, B           : Who_Knows_What;
   ...
   Widgets.Run (Object_Pointer);
   Widgets.Sleep (Object_Pointer);
   Widgets.Move (Object_Pointer);
   Widgets.Set (Object_Pointer, A, B);

Some Ada programmers feel that the code is easier to understand with the
dotted notation and some do not.  This is the "use clause controversy": 
Without a use clause, you are forced to use the dotted notation.  Some
Ada programmers feel that there is no one approach that is always best,
but that it depends on a number of factors, such as whether Widgets is a
well-known package whose facilities will be instantly recognized by all
programmers, whether lots of different facilities from lots of different
packages are all being used in the same place, whether the facilities
provided by the package have descriptive names, whether there are
name clashes among several packages being used in the same place, and
what kind of tools, from cross-reference listings to hypertext links, are
available to tell the program reader where any undotted names come from.

|> I don't see how passing "structs" to static functions differs from any other
|> function which takes a parameter.  In my mind, when I create a pointer to
|> an object of some user defined class, that one pointer takes any public
|> data and functions associated with the class.

You are certainly not alone in that respect, but I do not find it helpful
to create the fiction that a one-per-package subprogram or variable is
somehow "included" in all objects of a type declared in a package, and
pointed to by all pointers to objects of that type (especially since, on
occasion, it is most appropriate for the same package to provide more
than one type).

--
Norman H. Cohen    ncohen@watson.ibm.com