Re: Ada95 OOP Questions

[ecn@explorer2.clark.net (Eric C. Newton)]

In article <4tl235$a1v@news.ida.org> (David Wheeler) writes:

 < Lots of stuff comparing C++ and Ada object syntax deleted >

   The only difference is that, to dispatch in C++, you
   use a different syntax and the dispatching parameter is listed in
   a distinguished position.  In C++ the parameter is always called "this".
   In Ada, any parameter can be a dispatching parameter, and the
   syntax for calling the method doesn't change.

Lots of object-oriented languages support passing objects as
parameters, with one of those objects being "special".  For example,
the "first" argument is used for dispatch.  Modula 3 does this.
Python does as well.

<More stuff about C++ and Ada example code begin equivalent removed>

   : rather than a unified object that was like a combination of 
   : data and subprograms that enabled it to smoothly simulate an
   : entity?

   Data and subprograms are unified, but Ada thinks of structuring in
   terms of _packages_.  An Ada package with a tagged data structure 
   and subprograms using it defines a unified object definition.

   I think you're not understanding the key role of Ada packages.
   Packages are the _primary_ Ada structuring mechanism.
   In Ada, you can't "with" half a package.  When you "with" the
   package, you "with" the whole thing, data structures AND operations.

I do a lot of OO programming.  I like to learn new languages.  I even
kinda like Ada.  You're right, of course.  The only difference is
syntax.  But isn't that whole dispatch trickyness worth a bit of extra
syntax at the call site?  I have read many well argued articles by Ada
proponants convincing me that Ada takes the trouble to make many
things explicit.  It would seem reasonable to me that this would have
extended to something like dispatching.

To me,
	obj.method(arguments);

makes it pretty clear that "obj" will be used to dispatch.

When I originally read about Ada 95's support for polymorphism, I
thought that it *must* support multiple dispatch arguments.  That is,
if you can make any argument the "dispatcher", why not make more than
one argument the dispatcher (as in CLOS, or Cecil)?  For example,

	method(obj1, obj2);

would choose the correct method based on the run-time types of both
obj1 *and* obj2.  So I pulled down GNAT, coded up a test, and *slam*,
the compiler let me know in no uncertain terms that only one argument
could be used for dispatch.  So much for making silly assumptions.

Packages are good for structuring code.  Namespace control is
essential in large systems.  But objects are kinda handy abstractions
as well.  Relying on packages as the ONLY structuring mechanism makes
objects-as-abstractions a little more obscure because they don't
provide any structure by themselves.  

It's a pretty hard sell to say (pardon the syntax, 8-):

	struct Person;
	Eat(Person);
	Walk(Person);
	Talk(Person);

"That's a person.  It has the features 'Eat, Walk, Talk'."

Vs.
	class Person
	{
		Eat();
	 	Walk();
		Talk();
	};

Yes, they are equivalent.  Yes, a quick search for 'Class will tell
you what functions dispatch on Person.  I'm sure an experienced OO
person will be able to handle it.  Anyone who can read C++ code can
certainly learn to mentally group functions based on the type argument
passed.  I wouldn't want to teach object oriented programming to
anyone with this syntax, though.  For example, the following would be
bad style, and impossible to do in C++ and Modula-3, but legal Ada 95,
right?

   package Matrixes is

	type Matrix is abstract new Limited_Controled with private;
	type Vector is abstract new Limited_Controled with private;
	type Matrix_Access is access all Matrix'Class;
	type Vector_Access is access all Vector'Class;

	-- Get a row from a matrix
	function Row(M : access Matrix'Class; r : Natural) 
		return Vector_Access;

	-- Get an element from a vector
	function Element(V: access Vector'Class; i : Natural)
		return Real;

	-- Get a column from a matrix
	function Column(M : access Matrix'Class; c : Natural) 
		return Vector_Access;

	-- ... more stuff ...
   end Matrixes;

<Misconceptions about Ada's support for OO programming deleted>

I keep trying to see packages like I see objects and it just doesn't
get any easier.  Namespaces are good.  Objects are good.  Yes, Ada 95
has both, but it is pretty good at hiding the objects.  Ada has such
nice explicit support for all kinds of other programming abstractions.
There are times, especially when programming in C, that I find that I
could really use the kind of tools available in Ada.  I just don't
find myself wishing I could make a procedure dispatch on a type by
adding a keyword.

-Eric
-- 
Eric C. Newton        Software Reuser.
Newton Consulting     Look at all the code I didn't write today!
ecn@clark.net	      http://www.clark.net/pub/ecn/home.html