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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: "Jean-Pierre Rosen" Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/07/27 Message-ID: <6pi71p$n90$1@platane.wanadoo.fr>#1/1 X-Deja-AN: 375339180 Content-Transfer-Encoding: 8bit References: <6pdhfo$1br$1@platane.wanadoo.fr> Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: Adalog Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-07-27T00:00:00+00:00 List-Id: (In this discussion, we are discussing how to use classification in Ada; whether classification in itself is a good thing is a different issue; and I don't think I can be accused of being an inheritance fan ;-) Matthew Heaney a �crit dans le message ... >"Jean-Pierre Rosen" writes: > >> We are talking about classes here, and a class is an encapsulation of a data >> type together with operations. In that sense, a type is certainly not a >> class, since it addresses only the data-type part of a class. > >This is wrong. The defination of a type has _always_ been "data + >operations." The term "class" to designate a type is an unfortunate >mistake make by the designers of Simula. 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". >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". >> 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" ? In the second case, my notation would directly read "My_Account is an instance of Bank_Account". Other people may read it differently. However, If I personnaly prefer naming related to variables rather than type, it is because of a general principle that the client should be favoured against the server. In this case, a type is defined once, and used very often. I therefore prefer the name which is more descriptive in the general case. But this certainly a matter of opinions. >> but this is not the main point. The really important point is to use the >> same name for the main type of every "class package", because it allows you >> to have a uniform convention > >I don't understand what you mean. We've been calling files File_Type >for almost 20 years, and so far no one has complained. 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; 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. >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. -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog