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-7-bit X-Google-Thread: 103376,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/07/25 Message-ID: #1/1 X-Deja-AN: 374898509 References: <6pdhfo$1br$1@platane.wanadoo.fr> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 901403984 26234 bpr 206.184.139.132 Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-07-25T00:00:00+00:00 List-Id: On Sat, 25 Jul 1998, Jean-Pierre Rosen wrote: > >And whatever you do, please do NOT name a type "Object" or "Instance". > >This is a sure sign of confusion about the difference between a module > >and a type, which are orthogonal language features in Ada. > > > Well, since I was the first one to publish that notation (I do not claim to > be the first one who thought of it), let me follow up. > > 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. > > Rather, a class is a certain way of using a package, to declare a type and > associated operations (methods), and nothing else. Of course, there are > other ways of using packages: packages, as well as types and nearly any > other feature of the language, are building blocks that allow you to create > various paradigms depending on the way you put them together. > > However, if you agree that such a package corresponds to what is called a > class in OO languages, then it makes sense to name the package, not the > type, after the entity you want to represent. 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; I could follow your reasoning up to this point, but I think that it is a mistake to name a *type* something like Instance or Object, since an instance is more like a variable. If you want to adhere to the module = class style of OOP, where there is one main type in the package, then the Modula-3 convention of using the name "T" for the type, mentioned here previously by Fergus Henderson, seems more appropriate. The name Object or Instance should only appear on the left hand side of the declaration. Of course, this assumes that you are an orthodox OOer who doesn't coencapsulate types... -- Brian