Re: ADA Objects Help!

[dewar@cs.nyu.edu (Robert Dewar)]

Rob Wilkinson, if you cannot see that from a purely semantic point of view
there is nothing particularly special about member functions, then maybe
it is you who need a better C++ book.

You are viewing them through a semantic filter which says that you will
view these member functions in a special way, corresponding to a particular
paradigm that you (and the language design!) have in mind. However, if you
can manage to take a more basic viewpoint, you will see that member functions
are just functions, nothing more and nothing less. THey have a special
syntax and visibility, but that does not mean they are semantically
fundamentally different from ordinary functions.

YOu may just be to wrapped up in your viewpoint to see the point that several
people have made to you, certainly it does not seem to be registering.

Basically we have functions that can be used as ordinary functions and 
functions that you want to associate with a particular "object". Note
incidentally that at the language level, C++ does not have objects, it
has special structures that are called classes that may be particularly
well suited for the representation of objects, but they are not objects,
because the concept of object has to do with programming paradigms, NOT
with the language design.

In Ada 95, this same programming paradigm (objects and member functions,
probably better called methods in this context, since member functions is
just a syntactic designation), are represented by tagged types and associated
primitive subprograms with controlling arguments.

Just as in C++, classes and member functions may be used to represent
objects and methods, but of course have many other uses, in Ada 95,
tagged types and primitive operations of these types may be used
to present objects and methods.

The semantics in this correspondence are pretty much identical, although the
Ada 95 model is a little more flexible in that one can have more than one
appearence of the tagged type in the parameter list, which together act as
a controlling operand. THis is not important if you are strictly representing
objects and methods, but can be very useful in other contexts.

I think the reason that no one understands what you are saying, and 
consequently that you are getting frustrated, is that you are starting
out from some fundamental assumptions that are false:

   classes in C++ represent objects, false, they can be used to represent
   objects, but that is a programmer choice.

   member functions in C++ are methods. again false, they can be used for
   this purpose, but that is a programmer design choice.

Then you add to it your apparent feeling that this particular usage is
critical enough that it is important to give it a separate syntax. The
trouble is that this introduces multiple syntaxes for identical semantic
concepts (at the language level), and in the Ada 95 design we consider
it an advantage that no separate syntax is used. It leads to a much more
flexible capability, with all the power of the corresponding C++ constructs
and additional capabilities.

In C++, classes are often used for purposes other than the representation of
objects. For instance, in the absence of name spaces, they are used to
represent packaging of entities quite often, and in this context the special
syntax for member functions can definitely get in the way (e.g. if the
function is a binary operator operating on the class type).