Re: "use" clauses and Ada 95 OOP

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

"But my point is that a naive Ada 95 reader might think that the call

    pkg1.func(x)

calls the code that is in the body of pkg1."

Well naive readers can be confused in many ways, and one possible solution
is to de-naiveify the readers :-)

If people get compile time visibility and run time dispatching access
mixed up, they are missing a fundamental principle, and will run into
other problems.

I really don't see a problem, if you don't like the above, don't use it
and use USE clauses instead. You can't have it both ways, if you want
to emphasize visibility aspects by not using USE, then you are clearly
going to have this clash.

In C++, when you "import" a type, you get all its methods visible, i,e
the primitive operations in Ada terms. 

If you want this effect in Ada, you use USE, if you don't want it, you
don't use USE. Seems simple enough to me.

P.S. I really do not know namespaces in C++ at all, do they allow this
same separation of visibility from run time accessibility (if not I would
say that is a disadvantage, not an advantage).

What you have in Ada is a choice of two approaches. I personally have
no trouble with the notation above pkg1.func(x), but if you feel that
naive readers of your code *will* have trouble with this notation, then
by all means don't use the notation!

People who have learned to be 100% allergic to USE in Ada 83 will find
some discomfort here, but that's something they bring upon themselves.
The idea behind disallowing USE clauses is that it is a GOOD THING if
it is made VERY clear at the source level EXACTLY where the subprogram
being called is defined. BUT! the whole idea of dynamic dispatching
is to make absolutely sure that you can NOT tell at the source level
where the subprogram being called is declared. 

There is no clash between dynamic dispatching and the design of Ada, there
is a clash between dynamic dispatching and an insistence on never using
the USE clause, and that is really what Mitch is pointing out.

This really has nothing to do with f(x) vs x.f, since these notations
are equivalent, it has to do with whether or not you want to make
visiility explicit at the source code level. Neither f(x) nor x.f
does this, but package.f(x) does make this explicit (there is no
obvious syntactic analog in the x.f case).