Re: Don't use the "use" clause

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 26 Jan 2006 19:04:38 -0600, Randy Brukardt wrote:

> "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.

OK, without generics it might work.

>>> 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.

It should be up to the programmer. The language should not prescribe the
meaning of "*" or ".". However it can forbid overriding "." for certain
things, like packages.

> 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).

Well, I don't think that there should be such operator at all. Reference
types should inherit parent's operations, which in effect would mean their
full transparency. If ":=" should mean reference copy, then the reference
type have to override it.

>>> 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.

Packages have no properties of their own. Programs are written in terms of
types, objects, operations.

>> 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.

But it is not a string operation. It is a string-valued operation defined
on strings and numbers. Ada.Strings.Unbounded."*" is misleading. It could
be in Ada.Numeric or in Ada.Container. Actually, it is a reincarnation of
Hungarian notation for subroutines - an evil thing. Names should reflect
semantics, rather than types.

> I think you'd have a better argument if the routine was called
> "Replicate_String".

Take Is_Letter.

> 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.)

This is a no-use-friendly naming convention, especially useful for
generics. But that does not mean that there cannot be a use-friendly
alternative.

> 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.

Firstly, I think that introduction of prefixed notation probably was a
mistake. We'd better have removed it for tasks and protected objects.

Secondly, prefix notation as introduced in Ada 2005 is an equivalent of use
clause! In C++ both "use-" and "with-like-prefix" notations coexist. For
example:

   X.A::B::C::D::Foo (); // "with-like-prefix"
   X.Foo ();	   // "use-like-prefix"

Ada's equivalent of the first could be:

   X.Standard.A.B.C.D.Foo; -- Let's enjoy fully qualified names!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de