Re: Let's change semantics of "use type"

[Richard Riehle <richard@adaworks.com>]

Victor Porton wrote:

> I am suggesting (for the next Standard) to change the semantics of "use
> type" so that it would make visible not only primitive _operators_, but
> all primitive _operations_.
>

Snipped the explanatory text.

We should be cautious about adding features to the Ada
language that will dilute its essential power.   We should
be wary of trying to make Ada look like something else
in pursuit of a potentially ephemeral popularity.  Ada is
what it is:  a language designed to enable the compiler to
detect the maximum number of errors as early in the
development process as possible and to continue catching
errors during execution and over the full life-cycle of the
maintenance process.

Since Dr. Dewar has chosen to suspend his contributory
edification to comp.lang.ada for a while, it is probably
worthwhile to recall one of his most memorable and most
important admonishments about Ada versus other programming
languages.

       "Ada is meant to be more readable than writeable."

A corollary to this is that Ada is intended to be more traceable
than writeable.   Anyone who has had the entertaining experience
of slogging through pages of C or C++ code in search of (yes,
I know there are tools for this) some function or variable knows
the importance of this.

I am not a big fan of use type.   Frankly, I still believe that, for
really well-engineered software, the renaming of the operator
is still a good practice when there is only one.   As an alternative,
renaming the exact operators needed in a child package and
using that is better than a use type clause.

Dot notation serves a very useful purpose.  So does named
association.    In production code on weapon systems, both
are essential.

Toy programs and small programs don't require this kind of
rigor.  Programs that are long-lived and on which we expect
a lot of maintenance do benefit from dot notation.   While it
is more and more common to create software with a brief
lifetime in the Internet world,  this is not so common in the
large-scale software world.



Richard Riehle