From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c2f62556e56c9683 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: 'with'ing and 'use'ing Date: 2000/03/01 Message-ID: <89j5h5$j0j$1@nnrp1.deja.com>#1/1 X-Deja-AN: 591737169 References: <89h5lh$70r$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x42.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Wed Mar 01 13:21:43 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-03-01T00:00:00+00:00 List-Id: In article <89h5lh$70r$1@nnrp1.deja.com>, Ted Dennison wrote: > That's a very contraversial issue (odds are, you've just unwittingly > touched off another flamewar about it). Suffice it to say that many > people (myself included) think that's the "right" way to do things. Many > other people whose opinions I respect feel that's hogwash. So, when you are using existing packages that are already existing, the choice of whether to use USE or not is often dictated by the naming conventions of that package. When you design a package, you choose names that are designed either with the idea of USE in mind or not. It is really quite irritating to see a package that was carefully designed to be used with USE adopted into a program which blindly follows the no-USE policy, and end up with noise like: Angle_Handling.Angle_Handling_Options := True; As always, blind rules are just that, blind :-) Whether it is a good idea or not to avoid USE depends on many things, but the basic design point of view is to make things easier for the reader. This may partially depend on the environment. For example, if the readers have to suffer in an environment (they still exist :-( today) where there is no simple way to click on a name to immediately find out what package it is defined in, then putting dots all over the place may have some advantage in some cases for readers. What some people like to do is to use local abbreviations package MCA renames Major_Complex_Arithmetic; and then use MCA.xxx in the client. This to me seems the worst of both worlds, because now even a complete familiarity with the package is not enough to guess what is going on. If you must follow this approach, please standardize the abbreviations to be used and document them in the package itself, so that all clients use the same abbreviation. Indeed if everyone everywhere will use MCA as the "name" of this package, perhaps you should define a library level renaming of the package and with that, or even change the name of the package to MCA. My own taste is for a flexible approach. Use USE where it is helpful to do so, don't use it otherwise, don't have fixed rules (which are seldom a good substitute for judgment). The policy in the GNAT sources is to use USE in the compiler itself, it makes the code a lot clearer once you get to know the basic structure of the sources, since in 99% of the cases you immediately know where something is. For example, even a surface familiarity of the GNAT sources will tell you that Expand_N_Goto_Statement; must be in the package Exp_Ch5, since it is obviously an expansion activity, and we know goto's are a statement form defined in chapter 5. Furthermore, we assume that typically if you are working with the GNAT sources, you have reasonable locating tools available (such as are supplied with GNAT). For the run-time library, we mostly avoid the use of USE, since these sources are used in all kinds of contexts, and typically and frequently examined by people not very familiar with the library. It is relatively unusual (did any user ever do it?) to dip into the GNAT front end sources to answer a question about GNAT. It is quite common to dip into the runtime for this purpose. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy.