comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: use clauses
Date: Tue, 12 Apr 2022 20:05:00 -0500	[thread overview]
Message-ID: <t357jt$v7n$1@dont-email.me> (raw)
In-Reply-To: 62560a6b$0$18724$426a74cc@news.free.fr

"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message 
news:62560a6b$0$18724$426a74cc@news.free.fr...
> In article <s5vqq9$lou$1@franka.jacob-sparre.dk>,
> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>
>> For me, a naming scheme that discourages the use of (package) use clauses 
>> is
>> a bonus. (Such a scheme makes it easier to avoid use clauses.)
>
> I agree to avoid use clauses.
>
> (I personally prefer Lists.List, like Vincent Marciante -
> i like Ada.Containers.* naming :-) )
>
>
>> 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. That's not 
problem for overloadable primitive operations, since the profile is included 
and conflicts only occur when someone has made a lousy design choice 
(creating a routine with the same name and profile as a primitive) [Most 
such conflicts come from maintenance when some existing routine is moved to 
be primitive; in such cases, the original routine simply should be removed.] 
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..

> - 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). If your 
objects have well-choosen names, it's not really needed to have the type 
around for such operations, even when use clauses are in place. Thus, 
"Clear", not "Clear_List", and that 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).

> - 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. 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.

                         Randy.


  reply	other threads:[~2022-04-13  1:05 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17 21:45 Unchecked_Deallocation with tagged types DrPi
2021-04-17 22:29 ` Rod Kay
2021-04-17 22:36   ` Rod Kay
2021-04-18  9:06     ` DrPi
2021-04-18  9:07     ` Jeffrey R. Carter
2021-04-18  8:21 ` Dmitry A. Kazakov
2021-04-18  8:46   ` Gautier write-only address
2021-04-18  9:09     ` Jeffrey R. Carter
2021-04-18 10:13       ` Dmitry A. Kazakov
2022-04-16  3:44         ` Thomas
2022-04-16  8:09           ` Dmitry A. Kazakov
2021-04-18 10:20       ` J-P. Rosen
2021-04-18 10:34         ` Dmitry A. Kazakov
2021-04-18 15:14           ` J-P. Rosen
2021-04-18 15:23             ` Gautier write-only address
2021-04-18 15:53               ` J-P. Rosen
2021-04-18 16:08                 ` Gautier write-only address
2022-04-16  5:00                   ` Thomas
2021-04-20 18:53               ` Randy Brukardt
2021-04-20 19:35                 ` Dmitry A. Kazakov
2022-04-18  5:51                   ` Thomas
2022-04-18  6:26                     ` Niklas Holsti
2021-04-20 20:32                 ` Jeffrey R. Carter
2021-04-20 21:10                   ` Niklas Holsti
2021-04-21  8:35                     ` Jeffrey R. Carter
2021-04-21 10:11                       ` Dmitry A. Kazakov
2021-04-24  0:49                     ` Randy Brukardt
2022-04-18  1:51                       ` Thomas
2021-04-18 16:08         ` Jeffrey R. Carter
2021-04-18  9:13   ` DrPi
2021-04-18 10:01     ` Dmitry A. Kazakov
2021-04-18 10:42       ` DrPi
2021-04-18 16:48     ` Jeffrey R. Carter
2021-04-20 15:57       ` Stephen Leake
2021-04-20 17:24         ` Jeffrey R. Carter
2021-04-20 17:34           ` Vincent Marciante
2021-04-20 20:56             ` Jeffrey R. Carter
2021-04-21 10:21               ` Vincent Marciante
2021-04-21 10:28                 ` Vincent Marciante
2021-04-21 12:13                 ` Simon Wright
2021-04-21 13:28                 ` J-P. Rosen
2021-04-22 10:21                   ` Vincent Marciante
2021-04-21 13:42                 ` Jeffrey R. Carter
2021-04-24  1:04                 ` Randy Brukardt
2022-04-12 23:25                   ` use clauses Thomas
2022-04-13  1:05                     ` Randy Brukardt [this message]
2022-04-14  2:51                       ` 25.BX944
2022-04-14  6:49                         ` Emmanuel Briot
2022-04-15  5:33                         ` Doctor Who
2022-04-19  3:53                       ` Thomas
2022-04-19  5:59                         ` Randy Brukardt
2021-04-22  8:55           ` Unchecked_Deallocation with tagged types Stephen Leake
2021-04-22 11:16             ` Jeffrey R. Carter
2021-04-22 15:49               ` Vincent Marciante
  -- strict thread matches above, loose matches on Subject: below --
1986-08-06  2:08 USE clauses "David S. Bakin"
1986-08-07  1:09 ` alden%jade
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox