Re: Don't use the "use" clause

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

On Tue, 24 Jan 2006 17:38:12 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1wq3tkzfwt0bw.1ad4zqlgln451$.dlg@40tude.net...
> ...
>> But Standard cannot be declared within itself, even conceptually! (:-))
>> Anyway nested declarations are equivalent to "use"-ing.
> 
> Not really, direct visibility is a hiding relationship (new items hide old
> ones); use is a canceling relationship.

Well, let's consider a better (IMO) design, which would make "use" illegal
when it would cause any name conflict. The question is: will such
"safe-use" be OK?

>> I must admit, that I never managed to understand the point of use-haters.
>> (Probably because they don't have any (:-)) The packages comprise a tree.
>> With "use"-ing it is levered to a DAG. I would *really* like to be able to
>> do it without "use" as well, i.e. to have children of multiple parents. But
>> that's aside. Is the point that all nodes along any path need to be
>> mentioned? If so, then "use" or not is quite irrelevant. If not then what?
>> To keep it a tree, then "with" must be outlawed as well. I don't get it.
> 
> For me at least, it is about being able to find declarations sensibly -
> without having to rely on fancy tools which necessarily require the code to
> be complete and compilable.

I agree with this.

> Thus, strict limits on use clauses. Moreover,
> nested (direct) visibility is for the birds, in all of its forms. I want
> (and write) prefixes on *all* non-local declarations (with the exception of
> operators, which I consider a property more than a separate entity). That
> means that I do generally write Parent.operation for things declared in the
> parent of a child package. I hate it that the compiler will not allow me to
> enforce this.

Then you should answer the question above as no. Then also it is no matter
whether "use" hides anything. In my view it matters.

> Does this mean that I don't want child packages? Not at all; child packages
> are about extending the parent package. They give access to the entities of
> the private part that are otherwise not visibility in any way. I don't want
> any direct visibility on the parent, and think it is a mistake that it is
> there (it causes various anomolies that we've spent a lot of work
> eliminating from packages with just context clause relationships). Indeed, I
> probably would have modeled the child unit as a special kind of context
> clause, rather than using nesting.

I fully agree with this.

> Remember the difference between "visibility" (the ability to use an entities
> name) and "direct visibility" (the ability to an entities name without
> qualification). I want the former (of course), and only want the latter for
> local declarations.
> 
> 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.

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. For example,

- transitive "use",
- an ability to "use" things visible to another package,
- to merge declaration areas of several packages,
- to export the declaration area of a nested package (especially of an
instantiated generic package)
- proper renaming of objects.
- proper renaming of types,
- tools to prevent naming space contamination by generics.

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