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.9 required=5.0 tests=BAYES_00, T_FILL_THIS_FORM_SHORT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2a687662f09731bb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 26 Jan 2006 18:59:46 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1132227919.9036.51.camel@sonnenregen> <1132233886.11218.11.camel@sonnenregen> <1w17gk3manse1$.1kcsd6cj5scen$.dlg@40tude.net> <43d5f5cf$1_1@glkas0286.greenlnk.net> <1wq3tkzfwt0bw.1ad4zqlgln451$.dlg@40tude.net> <6NCdnfd8BcbcJEveRVn-pQ@megapath.net> <92132rehnlw6$.127gl4b6mfbnx.dlg@40tude.net> Subject: Re: Don't use the "use" clause Date: Thu, 26 Jan 2006 19:04:38 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-YMwA3M+Jxwz0+LAWJneVS0hSy1BHYaSI01am9wxE7UARfDjAx/L5/aSdbMk5Io5Fb6Jg61cQ1lheWEH!TW5DOhz4+lhYukoIv22duGMtSeOtQx7qcMD0ERMt8sIroctv8Dq9Ldi/lVzLE2ChFM/glxWQWUm7!OWUsUa9z6uqTJQ== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:2670 Date: 2006-01-26T19:04:38-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:92132rehnlw6$.127gl4b6mfbnx.dlg@40tude.net... > On Wed, 25 Jan 2006 15:46:06 -0600, Randy Brukardt wrote: ... > Anyway, differentiating between direct and indirect visibility introduces > aliasing, which is not a good thing. OK, you might say that eluding "use" > would prevent aliasing, but then that argument would hit child and nested > packages as well. It does. I think all packages should have the same sort of indirect visibility; I'd ban nested ones, and child ones would work the same as other library units. But that's not Ada. For Ada, avoiding child units just isn't possible, unless you want to build giant monolithic packages. So I have to take the bad visibility with the good extension and hiding features. Use clauses have no such good features -- they only have bad visibility. I'm afraid I didn't really realize how much of a problem visibility on the parent of a child unit is until we were working on limited with and private with. At lot of the anomolies only happened because of parent units. Of course, that was about 8 years too late for Ada... >> You want to get rid of selected notation? >Ideally "." should be an operation as any other, to override and to >overload. There has to be some basement in the syntax of operations/operators that never change. Otherwise, you end up with a write-only language. The visibility use of "." is one of those (obviously, you could use a different symbol than ".", but I think you need something whose meaning doesn't change for this purpose). Dereferencing is another matter, and it's unfortunate that Ada mixes the two up -- they're completely unrelated. Pascal's "^" operator would be better (and I agree that that should be overridable). ... > > So that there is no way to figure > > out where rarely used things are declared? An occurrence of "Blocked_Sum" in > > a program can be totally mysterious, while Message_Statistics.Blocked_Sum is > > much clearer. > > Why is it cleaner? It could only be if Message_Statistics were better known > than Blocked_Sum. That is a result of design, not a function of nesting or > other hierarchy. Packages are the root of all organization in Ada; it's only the packages that you have to know instantly to understand an Ada program with few use clauses. Having to know all of the entities in a program well to understand it is going to be information overload. > Example: I know well that "*" can multiply string by > number, but I cannot say where it is declared without searching through > ARM. "*" is a terrible name for a string operation, and (while I know it's there) it's not one that I'd ever think of. (It's certainly not a native operation of strings, and thus shouldn't be named with an operator. "*" is only for numbers and numerical abstractions.) In any case, I would write it as Ada.Strings.Unbounded."*" -- and then I'd know instantly that it is a string operation, and know where to look if I need to know more. I think you'd have a better argument if the routine was called "Replicate_String". But that was a previous point (I forget who said it) -- the name of this operation should just be "Replicate", and the package name or object name will tell you want is getting "Replicated". (That's the naming we used in Claw, for instance, very short names for only the operation, where either the object name or the package name tell you what the type is. If you use use clauses and call all of your windows W, your Claw program will be indecipherable. Tough, use better names.) Note that the prefixed call notation (introduced in Ada 2005) reduces the need for use clauses and traditional selected notation by using the object name instead. That maps very well to both the Claw naming and an otherwise use-free environment -- it should reduce the clutter in programs of people that don't use use clauses and increase the readability for those that do (by emphisizing the object, and thus the type, of the operation). A win-win situation... Randy.