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,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/07/28 Message-ID: X-Deja-AN: 375514862 Sender: matt@mheaney.ni.net References: <6pdhfo$1br$1@platane.wanadoo.fr> <6pi71p$n90$1@platane.wanadoo.fr> NNTP-Posting-Date: Mon, 27 Jul 1998 19:06:13 PDT Newsgroups: comp.lang.ada Date: 1998-07-28T00:00:00+00:00 List-Id: "Jean-Pierre Rosen" writes: > The *type* definition by itself only defines the data. It is the fact that > some operations are defined in the same *package specification* as the type > that makes them bound to the type. Yes, a package is an encapsulation > mechanism; it is the encapsulation that transforms a type + some operations > in a "class". When I think of "type," I don't just think of the statement type T is ...; I think of "type" as 1) The name of the type, introduced by a type declaration of the form "type T is ..." 2) The primitive operations of the type, which are the subprograms that take the type named T as a parameter, and are declared in the same package as the type declaration. I do not equate "type" with the statement "type T is ...", and that seems to be where you and I part ways. A type is more than that, as it comprises a name, some data, and some operations. You call this thing a "class," but I prefer to stick to Ada terminology. The Ada statement "type T is ..." tells me the name (and ultimately the representation), but that is not equivalent to a "type"; it isn't enough to be a type. > >The use of the convention "P.Instance" to refer to the "real" type name > >is very misguided, because it's as if you're trying to make a package > >into a type, which it is not. > In this case, the package is the "class". I don't make a distinction between "type" and "class." The Ada term is for type is "type," and the term "class" means "family of types." Again, let's go back to the RM: Text_IO.File_Type is not called File.Instance Ada.Strings.Unbounded.Unbounded_String is not called Ada.Strings.Unbounded_String.Instance Ada.Tags.Tag is not called Ada.Tag.Instance System.Storage_Elements.Storage_Element is not called System.Storage_Element.Instance Why don't Ada programmers like to do what's in the RM? > >> Now the package may declare > >> some utility types in addition to the "main" type; it makes sense to have > >> some notation to distinguish this main type. "Instance" or "Object" look > >> nice in a declaration like: > >> My_Account: Bank_Account.Instance; > > > >You may think it looks nice, but I read this and think "Je crois qu'elle > >est laide." Why not just > > My_Account: Bank_Account; > > This is a very important issue in naming, which is much more general than > even this discussion. > Should a type name be descriptive of what the *type* is, or should it be > descriptive of what the *variables* are ? > In other terms, when you read: > A : T; > do you read it as "A is of type T" or as "A is a T" ? Both. Because there is no difference. > In the second case, my notation would directly read "My_Account is an > instance of Bank_Account". When I see the declaration My_Account : Bank_Account; I think "My_Account is an instance of Bank_Account." How else would you interpret it? > Other people may read it differently. I have to believe you that there are "other people" who read it differently, but it seems pretty obvious to me that the declaration O : T; means "Object O is an instance of type T." If these people are that confused about the nature of a declaration, then I'm not sure a naming convention is going to be enough to end their confusion. > Then, you miss the real issue. Actually, I wrote a book some times ago (in > French, and I still don't have a publisher for the english translation, > anybody's listening? ;-), and I stumbled into the problem of a consistent > notation for generics. That was the main triggering reason for that > notation. Since you didn't seem to keep you backlog of Ada Letters, let me > summarize the issue. > > Assume (your notation): > package Bank_Accounts is > type Bank_Account is tagged... > -- operations .... > end Bank_Account; > > Assume that some bank accounts are "privileged" in some sense. You want a > generic to allow this on any bank_account: > generic > with old_account is new Bank_Account with private; > package Privileged_Account is > type ??? is new old_Account with private; > --- other operations > end Privileged_Account; What's wrong with the convention generic type Account_Type is new Bank_Account with private; package Privileged_Mixin is type Privileged_Account is new Account_Type with private; ... end Privileged_Mixin; > The trouble is that when you instantiate the generic, you can choose the > name of the new package, but not the names of what is declared inside, and > especially the type. I you want the type name to carry the useful > information, the type name should change with each instantiation! With my > notation, the package name carries the useful information, and therefore the > same convention can be used for packages obtained by generic instantiations > and for regular packages. I suppose you could just do another local type derivation, or declare a local subtype. This isn't a big issue for me. I'm happy enough to be able to determine the characteristics of the type once, at point of instantiation, rather than being reminded every object declaration. > >We obviously have philosophical differences about the nature of a type. > >Oh, well. I'll be in Paris in September: perhaps we can meet at a cafe > >to discuss it more over "une pression"! > I'd be glad to. Just drop me a note when you know when you are there. Oui, d'accord!