Re: Ada95 OOP Questions

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

Thomas said

"code. Using use here leaves you with no clue at all! And this "confusing"
point is not peculiar to dispatching calls: it occurs with Ada 83 derived
types as well. Not new, although the "search direction" is reversed in that
case.)"



Actually derived types are a little more problematical than that for the
"i never use use, all I have is grep" crowd.

If you forbid the use of USE you can still find a procedure call in 
your program

   xyz (a,b,c)

where xyz is nowhere in sight, it is not in the unit where the call occurs,
and it is not in any of the directly with'ed units. This happens if you
derive a type from say an exported subtype, you derive all the primitive
operations, and they are directly visible locally.

So grep will not be enough, even if you ban USE. Really you need decent
tools to build Ada programs, and relying on grep for locating defining
occurrences of subprogram references is pretty miserable (note for 
example that it fails in any case in the overloaded case). It is hard
for me to believe that there are Ada environments with no better 
capabilities than grep for finding things.

With GNAT, you have two possibilities. For static analysis, you can use
gnatf, and then if you like, use the emacs interface to get straight from
applied to defining occurrences. (note that soon we will integrate gnatf
with gnat1 making this possibility a bit more convenient).

Second, you can follow the call with gdb, which has the advantage of 
course of being a dynamic trace that follows dispatching calls. GDB will
then point right at the appropriate source location.

As to whether using dynamic dispatching makes programs less maintainable,
we do not have enough experience to know. There are isolated anecdotal
discussions on each side (one entertaining one was that the green design
team very specifically avoided introducing dynamic dispatching because they
had used Simula-67 extensively, and found exactly that large complex
Simula-67 programs were hard to maintain -- but that's just one
experience point, with one kind of application). Like any other feature,
there is a wide range from good-use to ab-use and it remains to be seen
where on this range typical OO applications will sit when the entire
life-cycle costs for large projects are considered.

It is interesting though to see a very clear statement that the motivation 
for banning use clauses is entirely tool driven in this case, or rather
we should say driven by lack of tools. It is interesting to wonder how
the use of USE clauses would be affected by good tools.

My preference is to write code that is unambiguous without any use of
qualification, i.e. to avoid reusing the same names in different packages,
because I think that is potentially confusing anyway. Then the code you
write can always be displayed with dots if you prefer dots -- dotted code
cannot necessarily be converted to non-dotted form.

Two tools would be useful in a compiler, both are on the thought list for
possible GNAT additions.

1. An option to ensure that even though you use dots, your references
would be unambiguous without them.

2. a dotifier tool

Of course I realize that if you are a confirmed anti-use person, then you
choose names differently, but I still find the package names and dots to
have a rather high noise-to-signal ratio when reading code.

A lot dpeends on the program. For example in GNAT, where generally you need
to be reasonably familiar with the structure of the front end to read the
code anyway, the compiler itself is written using USE, and you quickly
learn where things are (for example Analyze_Object_Declaration is obviously
in Sem_Ch3, the package that handles chapter 3 semantics, and we really do
not need to write Sem_Ch3.Analyze_Object_Declaration). On the other hand,
the run time library, with its 569 separate source files, is a place where
it is useful to use qualification extensively. We never use USE in library
specs (this is actually enforced by the compiler to some degree), and use
them only some of the time in library bodies for units that are clearly
intimately related, or very familiar.

As in all style matters, I don't like absolute rules, and for sure it is
annoying to see programs use units that have been designed for use without
USE and insisting on not using the USE, giving us highly useful names
like Posix.Posix_Error :-)