Re: Don't use the "use" clause

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

On Wed, 25 Jan 2006 15:46:06 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:jhy2wes1y8jp$.17t7iu2n10zu1$.dlg@40tude.net...
>> On Tue, 24 Jan 2006 17:38:12 -0600, Randy Brukardt wrote:
> ...
>>> Summary: "visibility" == good; "direct visibility" == bad (well, at least if
>>> not strictly limited).
>>
>> No. Both are bad because they couple things. I think that access should not
>> be equivalent to visibility, either direct or indirect.
> 
> I was speaking formally here. I think you're still confused about have
> "visibility" means in Ada, because something being visible means no more and
> no less than that it can be accessed by name (and how else can you access
> something?).

Name (identifier) is not the only way to access an object. Visibility
(common sense) is about access to names. The access to the indicated object
(full view, partial view etc) is another story.

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.

> Perhaps it would be better to talk about "potential visibility"
> or something like that.
> 
> When something is visible, all that means is that you can write its name
> (somehow) and possibly access the entity. Usually that somehow is through
> selected notation. If something is not visible, then you can't write its
> name in any way at all, including selected notation.

Exactly, see above.

>> As for visibility, ideally, there should be only direct one, provided that
>> the language would ensure consistency of all views and that it would have
>> tools to control it.
> 
> You want to get rid of selected notation?

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

> 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. Example: I know well that "*" can multiply string by
number, but I cannot say where it is declared without searching through
ARM.

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