Re: Elimination of "use" clauses

[Robert Dewar <robert_dewar@my-deja.com>]

In article <x7vso6xvsbw.fsf@pogner.moho>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:

> I first came across consistent renamings like this in the GNAT
> sources:
>
>   package body System.Pool_Global is
>
>      package SSE renames System.Storage_Elements;
>
> and thought it a pretty cool notion. is ACT changing its
style, then?
> (your privilege, of course!)

First: ACT /= Dewar. Just because I like something does not
mean my preference is what we do (I prefer all upper case
identifiers, but everyone else preferred mixed case, so that's
what we use, and now I am used enough to that and it is OK).

As for the specs, as you know, we have a convention of not
allowing use clauses in internal library packages that is
inspired by the rtsfind restrictions. General GNAT style is
to prefer general use of use clauses.

Most certainly we would not get into prefixing uses of
system.storage_units if it were not for the rtsfind
restrictions (se the GNAT sources if you want to find
out more about that).

But anyway, if you think this notation is cool, fine .. I find
it OK for very small units like these, but it is not something
I would use in larger units. For example, if you look at
g-spipat.adb, which I *did* write, it is 6000 lines long (the
SPITBOL pattern matching stuff is complex -- half is comments
but half is real code), and there is not one use of package
renaming, but there are use clauses, and this represents my
preferred style. Of course we DO have tools that allow us
to immediately locate a specific reference, and we use naming
conventions that minimize confusion.

One of the things I often see happening in big projects is that
there is simply no management control over the global name
space, so all kinds of different styles of naming coexist in
a program. I find that *really* horrible, and it does for sure
make it harder to figure out where things are.

In GNAT, if you see a name like Expand_N_Task_Body, you know
it must be in exp_ch9.adb, since it is clearly an expansion
routine, and you know that tasks are in chapter 9. The use
of Exp_Ch9.Expand_N_Task_Body would be entirely gratuitous
for anyone with the slightest familiarity with these sources
(and indeed annoying).

So part of the issue here is definitely control of name spaces.
I certainly agree that explicit naming may be more useful
when you have lost control of the name space.

One additional point, I really object to the use of
explicit qualification for dynamically overloaded primitive
operations of tagged types. Pointing back to the parent unit,
which is where the declaration is, but most certainly is NOT
where the executable code can be found, can often be quite
confusing.

If you see

   Module_Methods.List_Module;

it is an invitation to go to the body of Module_Methods to find
the code being executed, and of course in some sense the whole
idea of object oriented programming that makes use of dyamic
dispatching is that you CANNOT tell at the source level where
the code for some operation is located. Yes, it can correctly
point to the declaration, but far too often the declarations
are not sufficiently commented, and the feeling that the body
is a legitimate place to go to look to see how something works
is a common one, and one that can not be avoided with a lot of
inadequately commented code.

There, that should start another interesting subthread in the
old use discussion (incidentally, so far this thread has not
generated even one tiny small point that is new, but it seems
to be something that people like to talk about :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.