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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9768c08202fdbbb1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-11 07:59:47 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dennison@telepath.com (Ted Dennison) Newsgroups: comp.lang.ada Subject: Re: Let's change semantics of "use type" Date: 11 Nov 2002 07:59:47 -0800 Organization: http://groups.google.com/ Message-ID: <4519e058.0211110759.3ebbf128@posting.google.com> References: <3dcb8347$0$299$bed64819@news.gradwell.net> NNTP-Posting-Host: 65.115.221.98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1037030387 495 127.0.0.1 (11 Nov 2002 15:59:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 11 Nov 2002 15:59:47 GMT Xref: archiver1.google.com comp.lang.ada:30735 Date: 2002-11-11T15:59:47+00:00 List-Id: porton@ex-code.com (Victor Porton) wrote in message news:<3dcb8347$0$299$bed64819@news.gradwell.net>... > I am suggesting (for the next Standard) to change the semantics of "use > type" so that it would make visible not only primitive _operators_, but > all primitive _operations_. Ick. > The rationale is that this is a convenient way for dealing with a type > imported from a package without the need of many rename directives. These I've done quite a bit of tagged type programming in Ada95, and I have *never* used a rename that way. In fact, I don't believe I've used a single rename in Ada95 ever... > So in certain sense the current Ada is not perfectly readable.) With "use > all type" programmers will less tend to write multi-level designators > which are both unreadable (especially when there are several such Its "unreadable" only if things are misnamed. A decent Ada developer should realize how his services are going to look when the clients try to use them in code, and name them accordingly. > designators in an expression) and error-prone as one may forget y in > x.y.z (mistakedly writing x.z) and get wrong behavior of the program. I'm not exactly sure how that could happen. Routines can't be "primitive" and exist in different packages. So the situation you envision would not make it past the compiler. Additionally, anyone who makes a package that is named after an "uncle" package needs to be worked over with a cluestick until enlightenment is achieved.