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/09 Message-ID: <3373EAB5.73A0@sprintmail.com> X-Deja-AN: 240415867 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> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-09T00:00:00+00:00 List-Id: 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 The scheme I described attempts to be "semantically economical." If the programmer already has a good word or phrase that describes a concept, then he shouldn't have to waste mental energy just to find some modifier that adds some extra shading to the idea, just to generate a different identifier. Generating the different identifier should be mechanical. > Almost all uses of type names make it obvious > that the name is a type. So all you're doing is putting something on the > end to have a different name for the type, and preserve the name for use > by an object or, more typically, a subprogram parameter. Exactly! All that we _need_ here is to be able to generate a different identifier. We _don't_ need that identifier to add any new information -- because there really isn't any new information! (See below...) > So why not use > the shortest possible suffix, 2 characters: _T? Because it's ugly. No, it's because "T" is not an English word, it's an ad hoc abbreviation. The goal of finding a mechanical naming convention would actually be satisfied by this suggestion, but it would not satisfy an orthogonal goal: keeping as much as possible to standard English usage. > But > it wastes fewer characters than the equally ugly _Type. "Ugly" is in the eye of the beholder -- "beauty" tends to be whatever you've gotten used to. I used to be just as religious as you in rejecting this kind of suffix as "ugly". But now that I've seen how _practical_ and _useful_ it is to keep to a simple scheme like this, I've come to view it as quite elegant. Funny how one's tastes mellow out with age... :-) > Now, allow me to indoctrinate you into the one true religion. Like you, > I want to preserve the meaningful name (List, Queue, What_Ever) for use > by objects and parameters. Unlike you, I insist that suffixes add at > least some information. So I want my suffix to indicate what kind of > type we're dealing with, as well as differentiating the type name. I've actually toyed with this possibility, but I've come to the conclusion that it's a bad idea. First of all, it complicates the rules for a naming convention, which adds to the mental work load for both the author and the readers. Everyone would need a scorecard just to keep track of what words are type-marking suffixes and what suffixes need to be used when. In a group project, you wind up getting different people deciding they like a different subset of the suffixes, so readability deteriorates because of a lack of consistency. A minimal solution is mor economical: Just say that all types will be marked in the same mannter. (By the way, we can level a similar criticism against the AQ&S guide's "general" vs. "specific" noun phrase scheme: There are just too many different adjectives in English that can confer "specificness" to a noun phrase, and it's a waste of effort having to sort them all out. You wind up concluding, as I did, that it's better to just settle on one universal "objectness" marker ("The_") and be done with it. But then you need to take a step back and ask whether it's more practical to mark all the _objects_, or all the _types_ instead. My conclusion was that it's better to mark all the types.) The other problem I have with your scheme is that, if there _is_ some "extra information" that seems worthwhile to add to a name, then why only add it to the _type_ name? Why not add it to the _object_ names too? E.g., if you like to add "_Count" onto an integer type, it probably indicates something about the purpose of that integer type: It "counts" quantities of some kind of item, rather than, say, "identifying" individual items (which is another purpose integer types can serve). But if that fact is really important to your application, then it's really an inseparable part of the "base noun phrase" for your concept, and it should go onto the object names too: type Error_Count_Type is range 0 .. Error_Limit; ... Error_Count : Error_Count_Type; -- counts errors flagged so far versus type Error_Ident_Type is range Minimum_Error_Ident .. Maximum_Error_Ident; ... Error_Ident : Error_Ident_Type; -- identifies the last error flagged But, as you can see, you're still faced with the problem of generating a different identifier for the type. IMHO, if you can't justify tacking a suffix onto an object name, then it really doesn't add any useful information. Appending it onto the type name just wastes energy and adds confusion. If the only purpose it serves is to differentiate the type, a universal type marker would have been a simpler solution. That being said, I can understand how under some circumstances you might find it important to mark what _kind_ of type you're dealing with. (I might not agree, but I can understand it.) But if that's really important enough to do, then it ought to be equally important not only on the type name but on the object names too! For instance, a separate problem is what to do about naming a designated type and an associated access type. In this case, marking the access type as a "Pointer" type is useful: type Target_Type is tagged ... type Target_Pointer_Type is access all Target_Type'Class; Target : Target_Type; Target_Pointer : Target_Pointer_Type := new Target_Type; But once again, I'd want the rule to be simple and minimalistic: Just always mark access types (and access objects) with "_Pointer". > I use > many; here are a few: TOO many, IMHO. But if they're good for the type, they're good for the objects: > Numeric types: _Value, _Count, _Range > > Enumeration types: _Id, _Name > > Array types: _Set, _List I'd only call an array a "Set" or a "List" if it really implemented the semantics of a "Set" or a "List". But this implies that the array type is just the completion of some private type with subprograms that support the ADT in question, and the fact that it's really an array is just an implementation detail. But if this is _not_ the case, and you actually have an array type that is publicly _visible_ as an array type, then saying it's something else is misleading. I'd just say: type Target_Array_Type is array (Target_Index_Type range <>) of Target_Type; ... Target_Array : Target_Array_Type; > Record types: _Group, _Data, _Info > > Task types: _Agent, _Controller > > Private types: _Handle "Handle"? Huh? What information does _that_ add? _Every_ data type in Ada95 "handles" _some_ kind of data... ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------