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/12 Message-ID: <3376C2D0.4A0F@sprintmail.com> X-Deja-AN: 241005148 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> <3374E402.77A@sprintmail.com> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-12T00:00:00+00:00 List-Id: Robert Dewar wrote: > > John suggests > > << Uint : Uint_Type;>> > > UGH! No, I don't like that at all. Why choose a name for an object that > emphasizes the type of the object. I choose my object names to emphasize > the use of the variable at a higher level of abstraction. > > Suppose I have a universal integer value that is the size of operand 1. > Then I would never write the above line, instead I would write: > > Opnd1_Size : Uint; I see the misunderstanding now. I thought you were talking about the case where you were dealing with "universal integer" as the syntactic element currently being compiled, similar to "statement", "expression", etc. If that were the case, then in fact "universal integer" would _be_ the abstraction, and my suggestion would be appropriate. But here it seems you are just dealing with a data component of some other abstraction, and that component happened to be implemented using your internal representation for a universal integer. In that case, I wonder why expose the particular implementation of that value? It could be that a later design change results in that value being implemented differently. How about: Operand_1_Size : Operand_Size_Type; or better: type Operand_Type is ... record ... Size : Operand_Size_Type; ... end record; ... Operand_1 : Operand_Type; -- now can reference Operand_1.Size Operand_Size_Type might be derived from Uint, or it might just be a subtype of Uint, or it might (long shot) be a private type that hides a Uint, or... ah, but I see this opens up a whole other can of worms. It's the old apples and oranges question, and what's an apple versus an orange, and when do you really need distinct types? I won't try to argue the exact design decision you made here... Yes, if you decide to give one implementation type such broad usage without distinguishing different usages as distinct types/subtypes, then of course the variable names should not reflect the implementation. > Similarly, I cannot imagine calling a variable Integer, so where you > suggest > > Integer : Integer_Type; > > I would far prefer to write: > > Number_Of_Attempts : Integer; Isn't it bad form to over-use the standard integer types? Again, the apples and oranges question. In this case, I might have done: type Try_Count_Type is range 0 .. Try_Limit; -- Try_Limit might change, changing the implementation needed. -- Also, want to distinguish this from e.g. Error_Ident_Type. Try_Count : Try_Count_Type; > I have *never* wanted to call a variable Integer, and that is why in this > case Integer is the right name for the type. The cases I had in mind where you might want to do this are in defining the abstraction for "integer" itself, e.g.: function "-" (Integer : in Integer_Type) return Integer_Type; function Integer_Type'Succ (Integer : in Integer_Type) return Integer_Type; similarly: function "not" (Boolean : in Boolean_Type) return Boolean_Type; function Float_Type'Ceiling (Float : in Float_Type) return Float_Type; I can see this is a bit of a stretch: Is the real abstraction here the type being manipulated, or the functions themselves? I.e., is it more important in this case to emphasize which data abstraction the parameter implements, or is it more important to emphasize the role the parameter plays within the function, actually re-using the same role names across all the overloadings of the function? E.g., our current situation: function "<" (Left, Right : Integer) return Boolean; function "<" (Left, Right : Float) return Boolean; function "<" (Left, Right : String) return Boolean; ... versus the hypothetical: function "<" (Integer, Than_Integer : Integer_Type) return Boolean; function "<" (Float, Than_Float : Float_Type) return Boolean; function "<" (String, Than_String : String_Type) return Boolean; The fundamental question here is, when we deal with the built-in types and their operations, are we dealing with purely functional abstractions, or can we view these types as data abstractions comparable to typical abstract data types (Set, List, Queue, etc.)? If the latter, my naming convention can be made to fit them. If the former, my scheme is inapplicable. > On the other hand, there are cases where there is little separation between > the abstraction levels of the type and its use, e.g. when you have an > enumeration type where there is only one instance of the type, as in > > type System_Status_Type is (Going, Stopped, Terminating, Starting); > System_Status : System_Status_Type; > > in this case, a standard suffix is appropriate, and I favor using _Type > as the suffix in a case like this. Glad to see you agree... :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------