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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: "W. Wesley Groleau (Wes)" Subject: Re: Warning: Religious naming convention discussion :-) [was: assign help!!] Date: 1997/05/13 Message-ID: <3378BBD2.7BBA@this.message> X-Deja-AN: 241341127 Sender: usenet@most.fw.hac.com (News Administration) X-Nntp-Posting-Host: sparc02 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> Organization: Hughes Defense Communications Newsgroups: comp.lang.ada Date: 1997-05-13T00:00:00+00:00 List-Id: John G. Volan wrote: > W. Wesley Groleau (Wes) wrote: > > John G. Volan wrote: > > > Jeff Carter wrote: > > > > The problem with putting _Type on the end of all [sub]type names > > > > is that it adds no information. > > > But that's the whole point! Adding any more information is > > > _undesirable_ at this point, because presumably an object and > > > its type _both_ represent the _same_ concept > > > > If > > Angle : Angle_Type; > > is the only object of Angle_Type, > > Nope, that's a nice strawman, but that's not my position at all, > you're reading that into what I said. "Angle" is not necessarily > the only Angle_Type object _in the program_, but it may be the only > Angle_Type object _in a given local scope_. In that local context, So you are suggesting I have independent objects all named "Angle" all over the place? > why should I be forced to call that object anything other than the > simple word "Angle"? My answer is in the last two lines of this post (not counting .sig) > > then perhaps the declaration of > > Angle_Type is just clutter. (See my recent post about anonymous > > array types.) But "Angle" is rather vague. Might we in the future > > want to deal with more than one Angle? > > > > The "same concept" argument could be interpreted to recommend: > > > > Angle_1 : Angle_1_Type; > > Angle_2 : Angle_2_Type; > > Sum_Angle : Sum_Angle_Type; > > ..... > > Sum_Angle := Sum_Angle_Type (Angle_1) + Sum_Angle_Type (Angle_2); > > Again, quite a pretty strawman. (I can't believe you are being serious > here.) Straw(_Type) has nothing to do with it. I am not trying to start a flame war, but just to discuss different approaches. You apparently need to clarify, "presumably an object and its type _both_ represent the _same_ concept" > 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. Where besides in a few pragmas) is such confusion possible? > > If "adding any more information is _undesirable_" then I would say > > that a language construct that _must_ be there (though it adds nothing) > > is either a flaw in the language or (more likely) a sign that the > > program still needs some abstract thought. > > Go back a couple posts and look again. I was objecting to Jeff Carter's > suggestion of a whole smorgasbord of different type-marking suffixes for > the different classes of types. For example, for a floating point type, > you might have something like (not one of Jeff's examples but similar): In other words, you object to a recommendation that we _avoid_ "information hiding" :-) I object to that even more than I object to a blanket "_Type" suffix. 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". In fact, I consider it usually a milder form of the same sin you say Jeff promoted. > > Start_Point, Rotation, End_Point : Angle; > > ..... > > End_Point := Start_Point + Rotation; > > The synonym scheme again. This blithe violation of semantic economy > will cost you later if you decide to use the word "Point" to refer to a > two-dimensional cartesian-coordinate vector, and use "Rotation" to refer > to a rotational transformation matrix. It may be wiser to be thrifty > with your semantics from the start, and simply retain the word "Angle" > in your objects of Angle_Type: > > Start_Angle, Rotation_Angle, End_Angle : Angle_Type; "Synonyms" are not the Point :-) "Angle" would actually have been better than "Point" Either way, there's still no need for "_Type" to make the identifiers unique. The "_Type" suffix has been mandated by more than one project coding standard at more than one company. When on such a project, I comply. Nevertheless, the syntax almost always makes it plain which identifiers are (sub)types and which are objects, so "_Type" adds no meaning. The extra keystrokes are better used where they _do_ add information. THAT is what _I_ call "semantic economy." ---------------------------------------------------------------------- Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA Senior Software Engineer - AFATDS Tool-smith Wanna-be w w g r o l at p s e u l t 0 1 dot f w dot h a c dot c o m SPAM should be sent to I.want.one@mailbombs.for.idiots.org If you don't want to pay $500 (see 47 USC 227), don't send it here. ----------------------------------------------------------------------