Re: Don't use the "use" clause

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:92132rehnlw6$.127gl4b6mfbnx.dlg@40tude.net...
> On Wed, 25 Jan 2006 15:46:06 -0600, Randy Brukardt wrote:
...
> Anyway, differentiating between direct and indirect visibility introduces
> aliasing, which is not a good thing. OK, you might say that eluding "use"
> would prevent aliasing, but then that argument would hit child and nested
> packages as well.

It does. I think all packages should have the same sort of indirect
visibility; I'd ban nested ones, and child ones would work the same as other
library units. But that's not Ada.

For Ada, avoiding child units just isn't possible, unless you want to build
giant monolithic packages. So I have to take the bad visibility with the
good extension and hiding features. Use clauses have no such good
features -- they only have bad visibility.

I'm afraid I didn't really realize how much of a problem visibility on the
parent of a child unit is until we were working on limited with and private
with. At lot of the anomolies only happened because of parent units. Of
course, that was about 8 years too late for Ada...

>> You want to get rid of selected notation?

>Ideally "." should be an operation as any other, to override and to
>overload.

There has to be some basement in the syntax of operations/operators that
never change. Otherwise, you end up with a write-only language. The
visibility use of "." is one of those (obviously, you could use a different
symbol than ".", but I think you need something whose meaning doesn't change
for this purpose). Dereferencing is another matter, and it's unfortunate
that Ada mixes the two up -- they're completely unrelated. Pascal's "^"
operator would be better (and I agree that that should be overridable).

...
> > So that there is no way to figure
> > out where rarely used things are declared? An occurrence of
"Blocked_Sum" in
> > a program can be totally mysterious, while
Message_Statistics.Blocked_Sum is
> > much clearer.
>
> Why is it cleaner? It could only be if Message_Statistics were better
known
> than Blocked_Sum. That is a result of design, not a function of nesting or
> other hierarchy.

Packages are the root of all organization in Ada; it's only the packages
that you have to know instantly to understand an Ada program with few use
clauses. Having to know all of the entities in a program well to understand
it is going to be information overload.

> Example: I know well that "*" can multiply string by
> number, but I cannot say where it is declared without searching through
> ARM.

"*" is a terrible name for a string operation, and (while I know it's there)
it's not one that I'd ever think of. (It's certainly not a native operation
of strings, and thus shouldn't be named with an operator. "*" is only for
numbers and numerical abstractions.) In any case, I would write it as
Ada.Strings.Unbounded."*" -- and then I'd know instantly that it is a string
operation, and know where to look if I need to know more.

I think you'd have a better argument if the routine was called
"Replicate_String". But that was a previous point (I forget who said it) --
the name of this operation should just be "Replicate", and the package name
or object name will tell you want is getting "Replicated". (That's the
naming we used in Claw, for instance, very short names for only the
operation, where either the object name or the package name tell you what
the type is. If you use use clauses and call all of your windows W, your
Claw program will be indecipherable. Tough, use better names.)

Note that the prefixed call notation (introduced in Ada 2005) reduces the
need for use clauses and traditional selected notation by using the object
name instead. That maps very well to both the Claw naming and an otherwise
use-free environment -- it should reduce the clutter in programs of people
that don't use use clauses and increase the readability for those that do
(by emphisizing the object, and thus the type, of the operation). A win-win
situation...


                               Randy.