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: Matthew Heaney Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/08/02 Message-ID: #1/1 X-Deja-AN: 377165798 Sender: matt@mheaney.ni.net References: <6pdhfo$1br$1@platane.wanadoo.fr> <6pi0pf$df8$1@nnrp1.dejanews.com> <6pirk1$iar$1@nnrp1.dejanews.com> <6pknai$qst$1@nnrp1.dejanews.com> <6pl5rh$elr$1@nnrp1.dejanews.com> <35BF50B4.6FDCDDA0@west.raytheon.com> NNTP-Posting-Date: Sun, 02 Aug 1998 01:55:29 PDT Newsgroups: comp.lang.ada Date: 1998-08-02T00:00:00+00:00 List-Id: Simon Wright writes: > Matthew Heaney writes: > > > You get the idea. Everywhere where I declare a file instance, the type > > is named Sequential_File. > > > > Now, suppose that as a build the software, or a requirement changes (not > > unlikely), I realize that I need direct file access, not just sequential > > access. The means I have to do a new instantiation, and everywhere > > where there's a Sequential_File, there's now needs to be a Direct_File. > > So why not call them just File? (OK, you can't "use" with such gay > abandon, good thing too :-) Because that's what I want to call the instance of the type: File. In an Ada declaration, the object and the type can't have the same name. If the object is called File, then the type has to be called something else. (Note that Eiffel doesn't have this "problem," because the object and its type are in different namespaces.) That's why I recommend using a two-word phrase to name types. General types like Integer don't have to follow this convention, because there's no danger of an object ever being named Integer. I gave reasons in the previous post why you should use the _Type convention only for certain situations (as an indicator of "static polymorphism"). To use that convention everywhere only adds noise that your reader is going to have to mentally remove. Someone responded by arguing that you could do this: declare File : Configuration_IO.File; begin but I don't care for this because it has the same problem as Jean-Pierre's Package_Name.Instance convention: it tries to elevate the package name to the same status as a type name. A package name is not a type name, because a package is not a type. A package is a namespace, and it exists only (more or less) to prevent name clashes among identically named types. Use expanded name notation ONLY when you have identically named types in the same scope. Please do not use expanded name notation to prevent a name clash between object name and the type name. You might argue that you could name the object, instead of the type, using the long form: declare Configuration_File : File; begin but this too is a mistake. You only need to state the properties of the object _once_, during its declaration. When you use the long form for the object, then you are adding noise everywhere the object is used, which the reader is just going to mentally strip out anyway. The idea is that you should say what you want to say by stating as little information as possible. This is the essence of abstraction. If the reader wants more information, then give him an easy path to find it.