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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2078dddcdcd8d83 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Warning: Religious naming convention discussion :-) [was: assign help!!] Date: 1997/05/13 Message-ID: <3379606E.413E@sprintmail.com> X-Deja-AN: 241420748 References: <5kjvcv$evt@news.cis.nctu.edu.tw> <5kn8ko$jcc@top.mitre.org> <1997May7.201035.2439@nosc.mil> <33727EEA.2092@sprintmail.com> <5kuf1j$17vi@uni.library.ucla.edu> <3373666A.31DFF4F5@spam.innocon.com> <3373EAB5.73A0@sprintmail.com> <33776FA6.3F78@this.message> <33779E0D.61F8@sprintmail.com> <3378BBD2.7BBA@this.message> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-13T00:00:00+00:00 List-Id: Sorry I got abrasive before, I don't really mean to start a flame war either. But to address your points: W. Wesley Groleau (Wes) wrote: > > So you are suggesting I have independent objects all named "Angle" > all over the place? Sure. Why not? package Angles is type Angle_Type is digits ...; -- in degrees subtype Proper_Angle_Type is Angle_Type range 0.0 .. Angle_Type'Pred(360.0); subtype Signed_Angle_Type is Angle_Type range -180.0 .. Angle_Type'Pred(+180.0); -- Angle_Type primitives (inheritable on derivation): function Get_Complement -- = 90 - Angle (Angle : in Angle_Type) return Angle_Type; function Get_Supplement -- = 180 - Angle (Angle : in Angle_Type) return Angle_Type; function Get_Proper_Form -- a kind of "abs" for angles (Angle : in Angle_Type) return Proper_Angle_Type; function Get_Signed_Form -- a kind of "abs" for angles (Angle : in Angle_Type) return Signed_Angle_Type; ... end Angles; Here are at least 4 functions that contribute to an abstraction for Angles, there may be many more. Each of these functions takes an Angle and transforms it in some way. What shall we name the parameter in each? With "Angle_Type" as the name of the type, the simple name "Angle" is available. But if the type were already named "Angle", we'd have to find something else for the parameters. Should it be "The_Angle", as Booch would suggest? Do we have to resort to barbarous abbreviations such as "Ang" or "A"? Do we need to spend (i.e., waste) time hunting around for synonym for "Angle"? > You apparently > need to clarify, "presumably an object and its type _both_ represent > the _same_ concept" Maybe taking an example will help: What we have here is the concept of an "Angle" -- what one is, and what we can do with one. We have a package that encapsulates this concept, a type that implements a data abstraction for this concept, and formal parameters standing for instances of this concept being acted upon by primitive subprograms. One concept, versus multiple program entities all needing names that don't clash. Semantic economy means that I should only need to decide on the word that stands for the concept ("Angle"). At that point, the creative work of naming should be done, end of story. The names for the program entities should fall out automatically, without mental work: concept: "Angle" --> instance: "Angle" --> type: "Angle_Type" --> package: "Angles" > > Of course you can have as many Angle_Type objects as you like, > > prefixing (or even suffixing) the "Angle" word with whatever > > "specific" modifiers you like, e.g., > > > > Start_Angle, End_Angle, Rotation_Angle : Angle_Type; > [snip] > > My scheme has the advantage that a "specific" identifier such as > > "Start_Angle" is clearly the name of an object, .... > > ...(and "specific" is the way AQS recommends making the distinction)... > > > ... and can never be confused as the name of a "specific" derived- > > or sub-type of Angle_Type. > > in a group of statements, it's rather hard to confuse _any_ identifier > as the name of any (sub)type. It's also difficult to misinterpret > whether a colon is to the left or right of the identifier. Once correctly written and successfully compiled, that may be true. But when an author is actually in the process of writing the abstraction (or even some client code that uses the abstraction) keeping track of which identifiers stand for the types, vs the packages, vs the objects/parameters, vs the primitive subprograms, is easier to do if the distinctions between the identifiers follow simple systematic rules. > Where besides in a few pragmas) is such confusion possible? Booch-like style: package Angle_Set is new Set (Item => Angle, Count => Angle_Count); -- is this a type or a constant? Cohen-like style: package Angle_Sets is new Sets (Item_Type => Angle_Type, Count_Type => Angle_Count_Type); But, more important than any confusion on the page, there's the confusion in the mind, when the software is thought about or discussed. Although Robert Dewar has made the point that source code editors/browsers with cross-reference capabilities now make it easier to trace back to the original definition of an identifier, IMHO if the only reason you're bouncing back to the definition is just to recall what various things were named, then it's a waste, no matter how facilitated the bouncing. Better if you didn't have to bounce at all, but instead could just rely on a naming system that only requires you to remember what _concepts_ (object classes) you have in your application. (Clarification: I do think that this kind of cross reference browsing feature is useful, when it's applied to helping the reader understand the _semantics_ of the program, rather than just surface aspects like naming. For example, bouncing back to a type declaration to see what record components it contains, or bouncing to the body of a procedure to see exactly what algorithm is implemented there.) > In other words, you object to a recommendation that we _avoid_ > "information hiding" :-) Quite. > I object to that even more than I object to a blanket "_Type" suffix. Good. > I use "_Type" myself once in a while (on this > project, alwaysm its the law :-) ) but I still hold to my opinions that > it > is usually just five characters of "noise". Seems like quantum mechanics must apply to software, because this noise appears to be irreducible given the structure of the language. (To me, abbreviations are noise. :-) ) We're forced to distinguish identifiers somehow, but any distinction means adding some amount of noise. I just think distinctions that are self-evident in the surface form (syntax) of the identifiers is less mental work distinctions buried in the meanings (i.e. semantics) of the identifiers (e.g., "specific" vs. "general"). My question to you is this: is the "The_" in "The_Angle" noise? ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------