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 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3dbf2f325f33ce35 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Elimination of "use" clauses Date: 1999/07/12 Message-ID: <7mdnee$3s$1@nnrp1.deja.com>#1/1 X-Deja-AN: 500242830 References: <377B5807.88B875E0@cs.york.ac.uk> <7lh74s$v36$1@nnrp1.deja.com> <377CE178.6C15F543@hso.link.com> <7ljbsu$ni7$1@nnrp1.deja.com> <7ltl2q$mog$1@nnrp1.deja.com> <3784DC54.6463EDCA@decada.zko.dec.com> <7m3jfk$sud$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x27.deja.com:80 (Squid/1.1.22) for client 166.72.8.28 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Mon Jul 12 21:41:37 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-07-12T00:00:00+00:00 List-Id: In article , Simon Wright 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.