Re: Elimination of "use" clauses

["Michael F. Yoder" <yoder@decada.zko.dec.com>]

Robert Dewar wrote:
> 
> In article <3784DC54.6463EDCA@decada.zko.dec.com>,
>   "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote:
> >  It requires no
> > conscious thought or finger movement to realize that
> > 'Unb.Insert' comes
> > from the unbounded strings package.
> 
> Or perhaps unbounded trees, or perhaps the
> Universal_National_Boundaries package?

This is not a reasonable objection, because it assumes the worst
possible usage of the method.  (This *is* a strawman argument.)  If both
unbounded strings and unbounded trees were "withed" units, the
abbreviations would be something like UStr and UTree.  And
Universal_National_Boundaries would be abbreviated UNB, not Unb, if you
chose to allow acronyms.  (Using case to improve readability is
desirable even in a case-insensitive language.)

> I personally dislike these kind of package abbreviations. They
> are fine for people who know the code well, but they probably
> know where stuff is anyway.
>
> Otherwise you constantly have to be searching back to find out
> what peculiar abbreviations have been used.

This simply isn't so in my experience.  It takes at most one or two
readings of the renamings to internalize them.  If you are aware of the
method, you treat the renamings as an extension of the context clause;
and of course you should habitually read the context clause of a unit
before reading the unit.  Even if you aren't aware of the method, you
should read the global declarations at the top of a unit body.

It might be useful to this thread to give some history of the method I
discussed.  It was devised precisely because there was general
disgruntlement in our project about unreadability of code induced by
overly generous usage of use clauses.  On that project, the method
simply solved the problem.  Ever since then, I've not seen any case
where introducing such methods (or moving closer to them) hasn't
improved code readability even months or years after such changes.  To
me, the superiority of the method is an observed empirical fact; nor is
it a matter of what I am used to, since it wasn't the first method I
used.  I would certainly be willing to risk large amounts of money on
the method's being better than most others.

> [material about operators omitted]

Operators I prefer to treat as a separate question, because I believe
the best solution is different for operators and identifiers.  I have a
personal preference, but I don't feel it is clearly superior to other
methods.  With identifiers my experience has led me to a strong
preference.