From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!news.gegeweb.eu!gegeweb.org!fdn.fr!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed1-b.proxad.net!nnrp2-2.free.fr!not-for-mail From: Thomas Newsgroups: comp.lang.ada Mail-Copies-To: nobody Subject: Re: use clauses References: <607b56f8$0$3721$426a34cc@news.free.fr> <607bf826$0$3733$426a74cc@news.free.fr> <86im4hj6eh.fsf@stephe-leake.org> <827fce15-8277-4ec8-a627-01158b42a191n@googlegroups.com> <4205785c-6818-4e26-b931-5a775e2c426cn@googlegroups.com> <62560a6b$0$18724$426a74cc@news.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Tue, 19 Apr 2022 05:53:47 +0200 Message-ID: <625e324c$0$18369$426a34cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 19 Apr 2022 05:53:48 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1650340428 news-4.free.fr 18369 91.175.52.121:8270 X-Complaints-To: abuse@proxad.net Xref: reader02.eternal-september.org comp.lang.ada:63757 List-Id: In article , "Randy Brukardt" wrote: > "Thomas" wrote in message > news:62560a6b$0$18724$426a74cc@news.free.fr... > > In article , > > "Randy Brukardt" wrote: > > > >> I personally > >> only use "use type" in new code (there's tons of old code for which that > >> doesn't work, of course, but that doesn't change the principle). > > > > what do you think about: > > - "use all type" clauses? > > This is OK; I don't use them mainly because I only use features implemented > in Janus/Ada, and "use all type" is not yet implemented there. > > The fundamental problem with "use" is that it makes everything visible, and > then deals with conflicts by making those things invisible again. > Since "use all type" only works on overloadable primitives (and things that > work rather like primitives), it's fairly safe. One could make an argument > that primitive operations should always be visible when the type is (that's > not the Ada rule, but argubly it would work better in most circumstances) -- > and you should always know to look at primitives anyway when trying to find > something.. are you speaking about a case like Ada.Text_IO.Unbounded_IO? i would say that these subprograms are not primitives, since they are not declared in the same package, and i don't see in which case we could get a type visible but not its primitives. in this case, the best thing to do that i found is: use all type Ada.Text_IO.File_Type; use Ada.Text_IO.Unbounded_IO; is there sth best? BTW, i often get a repetition in the same declare bloc, like: File : Ada.Text_IO.File_Type; use all type Ada.Text_IO.File_Type; what do you think about generate an automatic "use all type" where the variable is declared? > > > - List.Clear? (could you remember me how you call that, please?) > > For tagged types, you can use prefix notation, so "My_List.Clear" is the > easiest. With "use all type List", you can write Clear(My_List). i asked for your opinion, because J-P. Rosen told me he doesn't like that. so i would like to know main usages, practicals, ... if i got it, you use prefix notation a lot, because you have no access to "use all type"? > ["Clear" works well even when someone uses > everything in sight] (of course, they may have a hard time finding where > Clear is defined when debugging, but that's their choice). are you sure? i would say either there is only 1 Clear for the type List, and if it's a primitive it's easy to know where to find it, or there are many Clear for the type List, and they are not visibles. > > > - List.Clear does work only if List is tagged? > > Right. There are a number of semantic issues for untagged types, the main > ones having to do with implicit dereference (which occurs in this notation, > as in any other selected_component notation). If you have a prefix of an > access type, it gets very messy to determine which dereference is which. And > just allowing composite types doesn't work well either: a private type that > is completed with an access type would *lose* operations when it had full > visibility -- that seems pretty weird. > > It originally got limited to tagged types as that was easy to do and didn't > have semantic issues. what's i don't understand is, there is sth which work better with tagged types than with untagged types, whereas tagged types are known to be more complex to give special functionnality, not to be simpler to use. could you give me a concrete example please, of a case where using prefix notation with an untagged type causes a particular problem, and then making the type tagged permits to resolve the problem? > We were going to look at generalizing the prefix > notation again (several people asked about it), but no one made a concrete > proposal and it never went anywhere for Ada 2022. (maybe i could make one if i understand enough? :-) ) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/