* assign help!! @ 1997-05-05 0:00 Ivan Gou 1997-05-06 0:00 ` Michael F Brenner 0 siblings, 1 reply; 103+ messages in thread From: Ivan Gou @ 1997-05-05 0:00 UTC (permalink / raw) This is very important to me, is any master-hand can help me? If you can help, please email me the above email address, thanks. This is the wrire_page part of the program, I have done so far: procedure write_page(page: in out page_type; line: in out text_line; next_line: in out text_line) is -- Writes out one full page of text. begin -- write_page --** Reset the page for i in 1..page_length loop for j in 1..col_num loop line:= ret_line(page(current_col)); next_line:= ret_line(page(current_col)); for k in 1..col_width loop put(line.buffer(k)); -- line 208 is here, what shall I put instead of 'line'? end loop; end loop; end loop; new_line; page_num := page_num + 1; for count in 1..(col_width * col_num /2) loop put(space); end loop; put("page "); put(page_num,2); new_line; new_line; end write_page; I have error in: typeset.adb:208:16: invalid prefix in selected component "line" typeset.adb:236:10: missing argument for parameter "line" in call to "write_page" You can ignore line 236 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: assign help!! 1997-05-05 0:00 assign help!! Ivan Gou @ 1997-05-06 0:00 ` Michael F Brenner 1997-05-07 0:00 ` Charles H. Sampson 0 siblings, 1 reply; 103+ messages in thread From: Michael F Brenner @ 1997-05-06 0:00 UTC (permalink / raw) > This is very important to me, is any master-hand can help me? > If you can help, please email me the above email address, thanks. > This is the wrire_page part of the program, I have done so far: I am a master-hand, and a world-class Ada programmer, however I cannot help for the following reasons: (1) This submission did not include the definitions of the types which it references: page_type, text_line, etc. (2) This submission did not include the definitions of the objects which it uses: page_length, col_num, current_col, col_width, buffer, page_num, space, line, etc. (3) This submission did not include the definitions of the methods which it invokes: ret_line, page, put, new_line, etc. (4) The above missing specifications, definitions, and elaborations make the program snippet ambiguous and therefore there are more than one correct answers to the question. It would have been fun to help, but without the parts, the whole is missing. This is very disappointing that the components are missing, because bemoaning the vagaries and bugs in the text_io design are a necessary step in the evolution of Ada programmers, many of whom are introduced to hacking (the next step above software engineering) by these very bugs! To start with, I advise the following: (A) make all of the type names plural English noun phrases, i.e. change page_type to pages, text_line to text_lines, natural to columns, natural to rows, etc. (This will make better use of the type checking facility, but more diagnostic messages will reveal the rest of the bugs, and your program will be more readable AS AN ENGLISH SENTENCE. That way you will avoid personal preferences for schemes that capitalize anything except the first letter of computer program and acroynyms.); (B) add the preconditions (e.g. after line 206 add the assertion <assert (col_width = 0)> to identify when the program works, by giving (preferably) executable conditions which are True at THIS point in the code); (C) add the postconditions (e.g. after line 209 add the comment <-- line (1..k) has been sent to the correct URL> so the reader of the code knows what has been accomplished, that is, what is True at THIS point in the code; (D) add the invariant conditions (e.g. after line 207 add the comment <-- There are col_width+1-k characters left of the slice line (1..k)> so the reader of the code knows that the loop is progressing and will actually terminate, because, for air conditioning purposes, the person running this program at the supercomputer lab has to be locked into the computer room with the source code diskette, and it gets very uncomfortable in their when a loop fails to terminate; (E) after doing the above, and providing the missing component definitions, and fixing the diagnostic messages which arise from introducing the assertions, comments, and strong typing, then resubmit the question and better advice can then be given that is more directly helpful to finding the exact path, rather than advice that just bullies the asker into facing the correct half of the compass, lost in the wide boulevard of errors contained in this programming snippet; (F) enjoy the process of creating programs with complex logic, and enjoy the process of simplifying that logic using the strong typing of Ada and the assertions (preconditions, postconditions, and invariant conditions) of the Ada methodology. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: assign help!! 1997-05-06 0:00 ` Michael F Brenner @ 1997-05-07 0:00 ` Charles H. Sampson 1997-05-08 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan 1997-05-10 0:00 ` assign help!! Simon Wright 0 siblings, 2 replies; 103+ messages in thread From: Charles H. Sampson @ 1997-05-07 0:00 UTC (permalink / raw) In article <5kn8ko$jcc@top.mitre.org>, Michael F Brenner <mfb@mbunix.mitre.org> wrote: > > ... I advise the following: > (A) make all of the type names plural English noun phrases, i.e. > change page_type to pages, text_line to text_lines, > natural to columns, natural to rows, etc. (This will make > better use of the type checking facility, but more diagnostic > messages will reveal the rest of the bugs, and your program > will be more readable AS AN ENGLISH SENTENCE. That way you > will avoid personal preferences for schemes that > capitalize anything except the first letter of computer program > and acroynyms.); This has nothing to do with the original poster's issue, but I have to disagree with you on this naming convention. I much prefer the one advocated by Ada Quality and Style: Type names should be general singular nouns and object names should be specific singular nouns, ex- cept for predicates as the names for boolean objects. (I don't just prefer it. I had some influence on its being in AQ&S that way.) The reason is that your program will be more readable AS AN ENGLISH SEN- TENCE. For example Error_Count : Natural; can be read as "Error_Count is a natural number". It could even be read as "Error_Count: Natural". Notice also, as the rationale to the naming section of AQ&S says, it's Integer, Boolean, and Character, not Inte- gers, Booleans, and Characters. Charlie -- ****** If my user name appears as "csampson", remove the 'c' to get my correct e-mail address. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-07 0:00 ` Charles H. Sampson @ 1997-05-08 0:00 ` John G. Volan 1997-05-09 0:00 ` Jay Martin ` (2 more replies) 1997-05-10 0:00 ` assign help!! Simon Wright 1 sibling, 3 replies; 103+ messages in thread From: John G. Volan @ 1997-05-08 0:00 UTC (permalink / raw) Charles H. Sampson wrote: > > In article <5kn8ko$jcc@top.mitre.org>, > Michael F Brenner <mfb@mbunix.mitre.org> wrote: > > > > ... I advise the following: > > (A) make all of the type names plural English noun phrases, i.e. > > change page_type to pages, text_line to text_lines, > > natural to columns, natural to rows, etc. (This will make > > better use of the type checking facility, but more diagnostic > > messages will reveal the rest of the bugs, and your program > > will be more readable AS AN ENGLISH SENTENCE. [snip] > This has nothing to do with the original poster's issue, but I > have to disagree with you on this naming convention. I agree with Charles, in that I disagree :-) with Michael's particular choice of a naming convention. However, I also disagree :-) with Charles' naming convention, see below... "Readability AS an English sentence" is not a very well-defined or well-bounded goal (although it is a worthy one, and I do applaud the sentiment behind it). Trying to get a programming language to mimic any natural language, and yet still fulfill its purpose to unambiguously specify programs, is a very hard problem (probably NP complete :-). English is particularly hard, because it is so fluid and flexible and ambiguous that almost any sequence of words could be interpreted as a sentence (given a certain poetic frame of mind). Yes, a naming convention for programming shouldn't gratuitously diverge from standard usage of English (or whatever your natural language happens to be). (4 instnc, IMHO, rsortng to ad hoc abrvtns z defntly bad 4m!) But, to be useful, a naming convention should be unambiguous, prosaic, and systematic -- in fact it should be downright mechanical! By this I mean that it should consists of simple, unambiguous rules, which (1) a program author could apply, with very little mental effort, to generate all the identifiers needed; and which (2) the readers of a program could apply, with very little mental effort, to instantly comprehend what those identifiers stand for. The more mechanical the rules, the better -- NOT because we're trying to take away from a programmer's "creativity". If anything, a mechanical naming convention can _liberate_ programmers so they can spend their energies applying their "creativity" to other more important goals -- like, actually writing programs that work! :-) A naming convention also ought to be "semantically economical." By this I mean that, once a programmer has come up with a word describing a certain concept in the target application (for instance, the name of a class of objects), he shouldn't be force to invent a _different_ word to represent the same concept -- in fact, doing so just serves to confuse the readers. Yet in Ada95, the same concept often must be mapped to several program entities, and they can't all get the same identifier: For example, let's say in our warfighting application domain we have a notion of a class of "Target" objects. An Ada95 programmer will tend to want to use "Target" as the name of a type, _and_ as the name of an object (variable, constant, parameter, record component) of that type, _and_ as the name of a function that returns a value of that type, _and_ as the name of the package that encapsulates the type and its primitive operations. But obviously something has to give here. (A similar problem arises in most other languages, too.) The only way to meet the goal of being "semantically economical" is to find some simple scheme for taking the basic name of your concept and "marking" it in some systematic way, to generate a family of derived identifiers. (More on this in a moment...) > I much prefer the > one advocated by Ada Quality and Style: Type names should be general > singular nouns and object names should be specific singular nouns, [snip] > (I don't just > prefer it. I had some influence on its being in AQ&S that way.) Oh, so you're the one ... :-) Seriously, I once was an staunch advocate of this very approach, but I have since come to find it unwieldy and impractical. By the criteria I described above, it fails miserably: The distinction between "general" and "specific" nouns is quite ambiguous and subjective, depending on context and point of view. It may take a lot of effort and hours spent poring over Roget's Thesaurus hunting for synonyms, and then more agonized hours deciding which synonym is more "general" and which more "specific". And for what? A percentage of your readers would've made the opposite decision you made, so where does that leave readability? Add to that the challenges of object-oriented programming, where you have "specific" subclasses inheriting from "general" subclasses. Would "specific" noun phrases like "Enemy_Target" and "Friendly_Target" represent _objects_ of type "Target", or would they be _types_ derived from "Target"? The only way I could find to hammer this into something even remotely approaching a systematic scheme was to follow Grady Booch's lead, and distinguish "definite" versus "indefinite" noun phrases. An unmarked noun such as "Target" is an "indefinite" noun phrase in English -- it does not refer to any specific instance of the concept. So that seemed appropriate as the name of a type. A "definite" noun phrase seemed appropriate as the name for a specific instance. To form a "definite" noun phrase, you have to add some "definite" adjective to the base noun, e.g.: The_Target : Target; This_Target : Target; That_Target : Target; and so forth. In fact, I used to resort to tacking "The" onto most every object name, as a sort of universal default marker for "objectness." (I made a distinction for record components: Since they "belong" to their record, I used the possessive "Its" instead of "The". For instance you'd get things like: "The_Target.Its_Location.Its_Latitude".) I used to push this scheme quite vehemently. However, the trouble with this approach is that it favors short type names at the expense of longer object names. Yet object names ought to be shorter, because they are referenced more often, in contexts that are more demanding on line-length (e.g., statements and expressions). Whereas types are used in contexts where you have more leeway to be verbose (e.g., in object declarations and parameter profiles). I have now come around to accept Norman Cohen's approach: An unmarked noun should be reserved for an object, e.g.: "Target.Location.Latitude". The name of the type should be the one that gets marked, and what better universal marker for "typeness" than "_Type"? e.g.: Target : Target_Type; Location : Location_Type; Latitude : Latitude_Type; Before you all shudder at this, let me point out that this is just as readable "AS English" as anything else: I can read this off as "Target is an object of Target_Type",etc. (No, you're right, I don't win any points here, since as I argued above, _anything_ could be read off as English -- but at least I don't lose any points, either.) You can still tack modifiers onto your object names to distinguish them from each other: Enemy_Target, Friendly_Target : Target_Type; but now there's no ambiguity about whether those modifiers mark the identifiers as object names versus type names. If you did need to have more "specific" type names, you'd still use the same "type-marker": type Enemy_Target_Type is new Target_Type with ... type Friendly_Target_Type is new Target_Type with ... Enemy_Target : Enemy_Target_Type; Friendly_Target : Friendly_Target_Type; This scheme is quick, painless and "semantically economical." We can get past naming questions and get on with the business of programming. > The > reason is that your program will be more readable AS AN ENGLISH SEN- > TENCE. For example > > Error_Count : Natural; > > can be read as "Error_Count is a natural number". It could even be read > as "Error_Count: Natural". What about: type Error_Count_Type is range 0 .. Error_Limit; -- i.e., don't resort to using a predefined integer type -- if you can avoid it... Error_Count : Error_Count_Type; I only wish the original designers of Ada83 had clued into this style from the start. I find myself wishing Ada95 looked more like this: Integer : Integer_Type; Natural : Natural_Type; Float : Float_Type; Boolean : Boolean_Type; Character : Character_Type; String : String_Type; Duration : Duration_Type; ... generic type Object_Type (<>) is limited private; -- vs. "Object" type Pointer_Type is access Object_Type; -- vs. "Name" procedure Ada.Unchecked_Deallocation (Pointer : in out Pointer_Type); -- vs. "X" ... procedure Deallocate is new Ada.Unchecked_Deallocation (Object_Type => Target_Type, Object_Pointer_Type => Target_Pointer_Type); -- instantiations are more understandable this way, because -- you can tell at a glance that these parameters are types, -- and not, say, objects or subprograms ... Target_Pointer : Target_Pointer_Type := new Target_Type; ... Deallocate (Pointer => Target_Pointer); ... package Ada.Exceptions is ... type Exception_Identity_Type is ... -- vs. "Exception_Identity" ... procedure Raise_Exception (Exception_Identity : in Exception_Identity_Type; -- vs. "E" Message_String : in String_Type := ""); -- vs. "Message" ... end Ada.Exceptions; ... Target_Error : exception; Target_Not_Found_String : constant String_Type := "Selected target not found."; ... Ada.Exceptions.Raise_Exception (Exception_Identity => Target_Error'Identity, Message_String => Target_Not_Found_String); Alas, alas, what might have been ... :-) > Notice also, as the rationale to the naming > section of AQ&S says, it's Integer, Boolean, and Character, not Inte- > gers, Booleans, and Characters. Well, I agree with Charles that you should stick to the singular when naming objects and their types. You can look at a type declaration as a description of a "single" thing, but at an abstract level: "This isn't any particular object, but this is what any given object of this type would look like." What still remains, however, is what to do about packages. Here again, I've come to adopt Norman Cohen's scheme: Use the plural for a package name. E.g.: package Targets is type Target_Type is ... procedure Blow_Up (Target : in out Target_Type); ... The plural makes sense for a package name, because a package is a logical grouping of related declarations -- a package, if you will, is "about" a topic. Topics are often discussed in the plural: "This package is about "targets" -- how you declare them, and what operations you can do with them." The plural form in English is usually very close to the length of the singular, which is good because package names will be referenced frequently (if you avoid "use" clauses). Usually an English plural is just one character longer than the singular ("Target" vs "Targets"), or two characters longer ("Company" vs "Companies"), or occasionally shorter (!) though these are for words derived from Latin ("Datum" vs. "Data") or Greek ("Phenomenon" vs. "Phenomena"). (For cases like "Fish" vs. "Fish", "Moose" vs. "Moose", "Deer" vs. "Deer", etc., that problem will have to be solved by the legions of engineers developing real-time embedded code for the Department of the Interior, the Nature Conservancy, and Greenpeace ... ;-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-08 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan @ 1997-05-09 0:00 ` Jay Martin 1997-05-09 0:00 ` John G. Volan 1997-05-09 0:00 ` Jeff Carter 1997-05-09 0:00 ` Kevin Cline 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 2 siblings, 2 replies; 103+ messages in thread From: Jay Martin @ 1997-05-09 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: ... >I only wish the original designers of Ada83 had clued into this style >from the start. I find myself wishing Ada95 looked more like this: > Integer : Integer_Type; > Natural : Natural_Type; > Float : Float_Type; > Boolean : Boolean_Type; > Character : Character_Type; > String : String_Type; > Duration : Duration_Type; > ... Two thumbs up! In fact wouldn't be cool if Ada forced all types to have "_Type" suffixes. Heh probably make those C hackers blood boil. Jay ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jay Martin @ 1997-05-09 0:00 ` John G. Volan 1997-05-09 0:00 ` Jeff Carter 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-09 0:00 UTC (permalink / raw) Jay Martin wrote: > In fact wouldn't be cool if Ada forced all types to have "_Type" suffixes. I take it this was suggested tongue-in-cheek, but actually it wouldn't be so hard to get a compiler to do that, if you really wanted to. GNAT for instance already includes the capability to do some style checking. Take a look at the -gnatr and -gnatg switches. > Heh probably make those C hackers blood boil. What do you mean? Would they be jealous that we could enforce a nice readable style when they couldn't, or would they incensed that we'd _dare_ to enforce a nice readable style when they _know_ the whole point behind computers is to be as creatively cryptic and as anarchically obfuscated as possible so as to overthrow any vestige of authority and establish themselves as a guru priesthood (bow three times toward Redmond) selling row after row of slick ten-pound glossy-covered how-to books to the masses of glazed-eyed zombie Internet lemmings? :-) :-) :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jay Martin 1997-05-09 0:00 ` John G. Volan @ 1997-05-09 0:00 ` Jeff Carter 1997-05-09 0:00 ` John G. Volan ` (5 more replies) 1 sibling, 6 replies; 103+ messages in thread From: Jeff Carter @ 1997-05-09 0:00 UTC (permalink / raw) Jay Martin wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > ... > >I only wish the original designers of Ada83 had clued into this style > >from the start. I find myself wishing Ada95 looked more like this: > > > Integer : Integer_Type; > > Natural : Natural_Type; > > Float : Float_Type; > > Boolean : Boolean_Type; > > Character : Character_Type; > > String : String_Type; > > Duration : Duration_Type; > > ... > > Two thumbs up! > > In fact wouldn't be cool if Ada forced all types to have "_Type" suffixes. > Heh probably make those C hackers blood boil. > > Jay According to my religion, you guys are heretics. I will give the command to my followers that you should be killed on sight. Now, if I only had some followers ... The problem with putting _Type on the end of all [sub]type names is that it adds no information. 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. So why not use the shortest possible suffix, 2 characters: _T? Because it's ugly. But it wastes fewer characters than the equally ugly _Type. The only advantage of this approach is that it's a suffix, which is much better than a prefix. In distinguishing two words, the initial characters are the most important. Two words that are the same in the initial characters and differ only in the later characters are more likely to be confused than two words that differ in the first character. Thus, the Booch school of prefixing all objects and parameters with The_ is an abomination. 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 use many; here are a few: Numeric types: _Value, _Count, _Range Enumeration types: _Id, _Name Array types: _Set, _List Record types: _Group, _Data, _Info Task types: _Agent, _Controller Private types: _Handle I'm also creative in my use of parameter names, using Into, Before, After, From, To, and so on to avoid as much of this as I can: procedure Insert (Into : in out String; Before : in Positive; Value : in String); procedure Append (Onto : in out List_Handle; After : in Position; Item : in Element); However, List_Handle is probably a protected type, so instead we can write List.Append (After : in Position, Item : in Element); Continue in your heresy, and we will burn you alive. Convert, and we will merely behead you. Ha! Nobody expects the Sappish Inquisition! -- Jeff Carter PGP:1024/440FBE21 Auntie-spam reply to; try ( carter @ innocon . com ) "Now go away, or I shall taunt you a second time." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jeff Carter @ 1997-05-09 0:00 ` John G. Volan 1997-05-10 0:00 ` Aaron Metzger ` (4 more replies) 1997-05-09 0:00 ` John G. Volan ` (4 subsequent siblings) 5 siblings, 5 replies; 103+ messages in thread From: John G. Volan @ 1997-05-09 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` John G. Volan @ 1997-05-10 0:00 ` Aaron Metzger 1997-05-11 0:00 ` Simon Wright ` (2 more replies) 1997-05-10 0:00 ` Robert Dewar ` (3 subsequent siblings) 4 siblings, 3 replies; 103+ messages in thread From: Aaron Metzger @ 1997-05-10 0:00 UTC (permalink / raw) John G. Volan wrote: > But once again, I'd want the rule to be simple and minimalistic: Just > always mark access types (and access objects) with "_Pointer". > You really put a different spin on the whole debate with this example. Up to this point I think people were just expressing different naming conventions for types and objects in the "problem" space. With "_Pointer" you are stepping into implementation details. Maybe in a small local scope such conventions won't hurt you too much but I hope you don't propose suffixes such as _Pointer, (or others that I combat daily --> _Record, _List, _Array) for any type names that are exposed in package specs. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Aaron Metzger @ 1997-05-11 0:00 ` Simon Wright 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan 2 siblings, 0 replies; 103+ messages in thread From: Simon Wright @ 1997-05-11 0:00 UTC (permalink / raw) Aaron Metzger <ametzger@erols.com> writes: > I hope > you don't propose suffixes such as _Pointer, (or others that I combat > daily --> _Record, _List, _Array) for any type names that are exposed in > package specs. Since access types are so important in class-wide programming (Rationale II.2) I think their names will have to be visible sometimes. -- Simon Wright Work Email: simon.j.wright@gecm.com GEC-Marconi Radar & Defence Systems Voice: +44(0)1705-701778 Command & Information Systems Divsion FAX: +44(0)1705-701800 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Aaron Metzger 1997-05-11 0:00 ` Simon Wright @ 1997-05-11 0:00 ` Robert Dewar 1997-05-11 0:00 ` Robert A Duff ` (2 more replies) 1997-05-12 0:00 ` John G. Volan 2 siblings, 3 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-11 0:00 UTC (permalink / raw) John G. Volan wrote: > But once again, I'd want the rule to be simple and minimalistic: Just > always mark access types (and access objects) with "_Pointer". Bad suggestion. Access types are NOT pointers. They may be implemented using pointers some of the time (but not all the time -- we often find people using GNAT being surprised to find that access types are not always represented using simple pointers in some cases, but of course there is nothing in the language that suggests or requires that access types be implemented using pointers). Suffixing access types with _Pointer emphasizes the confusion, and seems inappropriate to me. It is analogous to saying that all integer types should be suffixed with _Twos_Complement_Bit_String or somesuch. Names should be chosen to emphasize the meaning at an appropriate level of abstraction, not the low-level implementation dependent representation. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert Dewar @ 1997-05-11 0:00 ` Robert A Duff 1997-05-12 0:00 ` Robert Dewar 1997-05-11 0:00 ` John G. Volan 1997-05-12 0:00 ` Kaz Kylheku 2 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 1997-05-11 0:00 UTC (permalink / raw) In article <dewar.863365392@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >Bad suggestion. Access types are NOT pointers. They may be implemented using >pointers some of the time (but not all the time -- we often find people >using GNAT being surprised to find that access types are not always >represented using simple pointers in some cases, but of course there is >nothing in the language that suggests or requires that access types be >implemented using pointers). I disagree. I think "pointer" means "thing that can point". I don't think it's a low-level machine-oriented concept at all. I use the term "address" or "machine address" for the low-level notion. I would amend your last sentence to say, "... there is nothing in the language that suggests or requires that access types be implemented as machine addresses." Note that Pascal calls them "pointers", not "access types", and there is nothing in Pascal that suggests or requires pointers to be implemented as machine addresses. This is even true of C, and there are in fact implementations of C that implement "foo*" as something other than an address -- for the purpose of doing bounds checking and whatnot, which is very expensive in C, but nonetheless useful for debugging. If I have a private type whose full type is some sort of index into a table, then I'm perfectly happy to call that a "pointer", even though it's not implemented as an address, and it's not even implemented as an access type. People talk about Lisp/Smalltalk/etc as languages in which "everything's a pointer", which is an informal phrase intended to mean that all the variables and whatnot have reference semantics -- not that they're all implemented as machine addresses (which they might be, but that's irrelevant). So, no, I don't think that "pointer" universally means "address". It does only in the minds of some people who have only been exposed to languages that allow or encourage address arithmetic on something called "pointers". If people with that background learn a higher-level language, they simply have to learn that access types, or reference types, or pointer types, simply aren't addresses. Analogy: You might say that some programmers assume that "procedure calls" involve a call instruction at the machine level. Therefore, we shouldn't call them "procedure calls" in Ada, because compilers might do inlining (either in response to pragma Inline, or automatically), and using the term "call" therefore confuses. >Suffixing access types with _Pointer emphasizes the confusion, and seems >inappropriate to me. It is analogous to saying that all integer types >should be suffixed with > > _Twos_Complement_Bit_String > >or somesuch. Names should be chosen to emphasize the meaning at an >appropriate level of abstraction, not the low-level implementation >dependent representation. I don't buy the analogy here. Two's complement bit-string *is* a low-level machine-oriented notion. Address is. But Pointer is not, at least for a substantial portion of the software industry. - Bob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert A Duff @ 1997-05-12 0:00 ` Robert Dewar 1997-05-12 0:00 ` Robert A Duff 0 siblings, 1 reply; 103+ messages in thread From: Robert Dewar @ 1997-05-12 0:00 UTC (permalink / raw) <<I disagree. I think "pointer" means "thing that can point". I don't think it's a low-level machine-oriented concept at all. I use the term "address" or "machine address" for the low-level notion. I would amend your last sentence to say, "... there is nothing in the language that suggests or requires that access types be implemented as machine addresses." Note that Pascal calls them "pointers", not "access types", and there is nothing in Pascal that suggests or requires pointers to be implemented as machine addresses. This is even true of C, and there are in fact implementations of C that implement "foo*" as something other than an address -- for the purpose of doing bounds checking and whatnot, which is very expensive in C, but nonetheless useful for debugging.>> says Bob Duff, and I agree in theory, but in practice, say pointer to most people, and then think of a machine address ... it is that perception of connection that causes confusion. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` Robert Dewar @ 1997-05-12 0:00 ` Robert A Duff 1997-05-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 1997-05-12 0:00 UTC (permalink / raw) In article <dewar.863448507@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >says Bob Duff, and I agree in theory, but in practice, say pointer to >most people, and then think of a machine address ... it is that >perception of connection that causes confusion. Well, at least we agree "in theory". ;-) In practise, I *like* the word pointer (with it's fairly high-level meaning), and I'm not about to give it up to those who think it means, merely, "machine address". Who are these "most people"? There are a lot of C and C++ programmers in the world, and yes indeed many of them think pointer=machine address. Sigh. They're wrong, of course, since it's not even true in C or C++, much less Pascal or Ada or Lisp or .... To paraphrase a recent quote from you in a different thread: "Get rid of such people, either by educating them, or by getting rid of them." Anybody who's got experience in a language where "pointer" doesn't allow (e.g.) address arithmetic, and anybody who's programmed in a language where "everything's a pointer", can understand the difference. I mean, by your reasoning, we shouldn't call Ada's arrays "arrays", because they might be confused with C arrays, which are a very low-level notion indeed! ;-) (And, by the way, I have no objection to a language with associative arrays calling *those* things arrays, even though some poor, low-level, Ada programmer might think they're getting a contiguous chunk of storage with random access performance. ;-)) So I'm sticking to my meaning of "pointer", which I think is shared by at least a substantial minority of software folk: It's a pointer if it points -- i.e. if you have reference semantics. That is, if you modify what X points to, and what Y points to can see the change, you've got reference semantics. That's why I sometimes say, "So-and-so (an index into an array) points to such-and-such thing (an element of that array)." (In fact, I said such things about array indices when I was programming in assembly language!) - Bob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` Robert A Duff @ 1997-05-12 0:00 ` Robert Dewar 1997-05-13 0:00 ` Robert A Duff 1997-05-13 0:00 ` David L Brown 0 siblings, 2 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-12 0:00 UTC (permalink / raw) Bob Duff said <<I mean, by your reasoning, we shouldn't call Ada's arrays "arrays", because they might be confused with C arrays, which are a very low-level notion indeed! ;-) (And, by the way, I have no objection to a language>> Why are C arrays very low-level notions? I agree they are often used this way, but I don't see this from the standard. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` Robert Dewar @ 1997-05-13 0:00 ` Robert A Duff 1997-05-13 0:00 ` Kaz Kylheku 1997-05-13 0:00 ` Robert Dewar 1997-05-13 0:00 ` David L Brown 1 sibling, 2 replies; 103+ messages in thread From: Robert A Duff @ 1997-05-13 0:00 UTC (permalink / raw) In article <dewar.863495951@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >Why are C arrays very low-level notions? Because: 1. They don't carry their length (or bounds) with them. You have to pass this information "by hand", as a separate thing. 2. There are no "whole array" operations, such as assignment and comparison. (Yes, there are library functions for these, but they don't operate on whole arrays -- they take pointer-to-first-element and size/length parameters separately.) 3. You can't pass an array as a parameter -- you have to pass a pointer to the first component, instead. (Or, looking at it a different way, an array *is* a pointer to the components. C is pretty confused on this point.) And having done that, there's no way to tell, in the language, whether a given formal parameter of type t* is pointing to a t, or to the first element of an array of t's. 4. Array indexing is defined in terms of pointer arithmetic. (Well, I admit this is a rather weak reason.) 5. The lower bound is always zero, rather than whatever makes sense to the programmer. E.g. if you want a table that maps the numbers A..B onto something-or-other, you have to subtract off A "by hand" All of the above give me the feeling that a C array is, conceptually, a pointer to a hunk of contiguous storage. That's a low-level, machine-oriented, notion. >I agree they are often used this way, but I don't see this from the standard. - Bob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` Robert A Duff @ 1997-05-13 0:00 ` Kaz Kylheku 1997-05-14 0:00 ` Robert A Duff 1997-05-14 0:00 ` Kevin Cline 1997-05-13 0:00 ` Robert Dewar 1 sibling, 2 replies; 103+ messages in thread From: Kaz Kylheku @ 1997-05-13 0:00 UTC (permalink / raw) In article <EA4J04.LpH@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: >In article <dewar.863495951@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >>Why are C arrays very low-level notions? > >Because: > >1. They don't carry their length (or bounds) with them. You have to >pass this information "by hand", as a separate thing. C structures don't carry a count of their elements with them either. Are they low level notions? >2. There are no "whole array" operations, such as assignment and >comparison. (Yes, there are library functions for these, but they don't >operate on whole arrays -- they take pointer-to-first-element and >size/length parameters separately.) This is more due to a quirk in the language which disallows an array from being a modifiable lvalue. However when arrays are embedded in structures, they may be assigned along with the structure, and may also be passed into functions by value, and returned from functions. >3. You can't pass an array as a parameter -- you have to pass a pointer >to the first component, instead. (Or, looking at it a different way, an You can also pass a pointer to the whole array. For example; typedef char user_id[8]; int user_exists(user_id *foo); The argument foo is a pointer to array of 8 char. Getting to the first character in that array would look like this: (*foo)[0] . In many circumstances, this technique is far preferred. >array *is* a pointer to the components. C is pretty confused on this >point.) C isn't confused: some C newbies are confused perhaps. It's a hard rule though. It's a major failing of the language that it doesn't provide ``bona fide'' arrays. It has to do with C's historical roots dating back to the B language. In fact, in the B language, arrays _were_ pointers. Arrays actually contained, in their first cell, a pointer to their data section. A pointer was just an array with no data section, just the pointer cell (declared by not writing anything between the square brackets as in ``int foo[]'' which would be interpreted in C as an incomplete array declaration). This became a problem in the design of C which allowed arrays to be embedded into structures---with no automatic initialization or finalization constructs, how would the cell be properly initialized inside a dynamically created structure? So Ritchie changed the rules so that evaluating an array would cause a pointer to its first element to be computed rather than loaded from a cell. A few badly behaved B programs had to be changed: those which actually played with the cell contents to relocate an array. The alternate notations for declaring a pointer argument to a function (e.g. char **argv and char *argv[]) are a merely a historic artifact left over from B. >And having done that, there's no way to tell, in the language, >whether a given formal parameter of type t* is pointing to a t, or to >the first element of an array of t's. That's unfortunate in many circumstances, though convenient in others. It's good in those circumstances when the extra array management overhead isn't needed. It's bad in those circumstances when a C programmer is forced to invent a more general array data type, such as a structure containing a length and a pointer to data. Today, I wouldn't think of designing a language without decent arrays. What I find appealing are two dimensional slice extractions. Even Ada doesn't have those! The ``Dragon Book'' gives a good discussion for the representation of arrays such that efficient extractions of rectilinear sub-arrays portion are possible. >4. Array indexing is defined in terms of pointer arithmetic. >(Well, I admit this is a rather weak reason.) These are all weak reasons for the argument that arrays are a low level construct; they are good reasons for some other claim though, such as the claim that C arrays are insufficiently general for some purposes. >5. The lower bound is always zero, rather than whatever makes sense to >the programmer. E.g. if you want a table that maps the numbers A..B >onto something-or-other, you have to subtract off A "by hand" If you program C long enough, nothing but zero based arrays makes sense! :))) >All of the above give me the feeling that a C array is, conceptually, a >pointer to a hunk of contiguous storage. That's a low-level, >machine-oriented, notion. Except that the elements of that hunk still have a type, possibly a const qualifier, etc. The true low level notion in C is that any object can be treated as though it were an array of characters, and that all storage is measured in characters. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` Kaz Kylheku @ 1997-05-14 0:00 ` Robert A Duff 1997-05-14 0:00 ` Kevin Cline 1 sibling, 0 replies; 103+ messages in thread From: Robert A Duff @ 1997-05-14 0:00 UTC (permalink / raw) In article <5laovr$l7t@bcrkh13.bnr.ca>, Kaz Kylheku <kaz@vision.crest.nt.com> wrote: >In article <EA4J04.LpH@world.std.com>, >Robert A Duff <bobduff@world.std.com> wrote: >>In article <dewar.863495951@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >>>Why are C arrays very low-level notions? >> >>Because: >> >>1. They don't carry their length (or bounds) with them. You have to >>pass this information "by hand", as a separate thing. > >C structures don't carry a count of their elements with them either. >Are they low level notions? No. C structures don't have a "give me the N'th component" operation, so of *course* they don't need to know how many components they have. The *do* know they're size, though (sizeof(x)). >>2. There are no "whole array" operations, such as assignment and >>comparison. (Yes, there are library functions for these, but they don't >>operate on whole arrays -- they take pointer-to-first-element and >>size/length parameters separately.) > >This is more due to a quirk in the language which disallows an array >from being a modifiable lvalue. However when arrays are embedded in >structures, they may be assigned along with the structure, and may also >be passed into functions by value, and returned from functions. What you call a "quirk" I call a major language design flaw. Anyway, I'm not sure what you mean by "more due to...". The fact is, in C, you can't pass arrays, but only pointers. That makes the notion of arrays "low level", IMHO. >>3. You can't pass an array as a parameter -- you have to pass a pointer >>to the first component, instead. (Or, looking at it a different way, an > >You can also pass a pointer to the whole array. For example; > > typedef char user_id[8]; > > int user_exists(user_id *foo); > >The argument foo is a pointer to array of 8 char. Getting to the first >character in that array would look like this: (*foo)[0] . >In many circumstances, this technique is far preferred. Granted. But it only works if the "8" happens to be a compile-time-known quantity, which if often isn't. And, anyway, inside user_exists, you can't know whether user_id is a pointer to a foo, or a pointer to an array of foo's. >>array *is* a pointer to the components. C is pretty confused on this >>point.) > >C isn't confused: some C newbies are confused perhaps. It's a hard rule >though. It's a major failing of the language that it doesn't provide >``bona fide'' arrays. It has to do with C's historical roots dating >back to the B language. OK, perhaps C isn't confused. I should have said "C is inconsistent", since sometimes an array is an array, and sometimes it's merely a pointer. And that *leads* to confusion. Don't blame the "newbies" -- the *language* is at fault here. The fact remains that within a function, a *thing could be a pointer-to-a-thing, or a pointer-to-the-first-element-of-an-array-of-things, and there's no language-defined way to tell. >In fact, in the B language, arrays _were_ pointers. Arrays actually contained, >in their first cell, a pointer to their data section. A pointer was just an >array with no data section, just the pointer cell (declared by not writing >anything between the square brackets as in ``int foo[]'' which would be >interpreted in C as an incomplete array declaration). This became a problem in >the design of C which allowed arrays to be embedded into structures---with no >automatic initialization or finalization constructs, how would the cell be >properly initialized inside a dynamically created structure? So Ritchie >changed the rules so that evaluating an array would cause a pointer to its >first element to be computed rather than loaded from a cell. A few badly >behaved B programs had to be changed: those which actually played with the cell >contents to relocate an array. The alternate notations for declaring a pointer >argument to a function (e.g. char **argv and char *argv[]) are a merely a >historic artifact left over from B. I don't know B. But I fail to see how blaming C's poor language design, in this area, somehow makes it "high level". Maybe B was quite consistent in this regard. So what? We're talking about C. >>And having done that, there's no way to tell, in the language, >>whether a given formal parameter of type t* is pointing to a t, or to >>the first element of an array of t's. > >That's unfortunate in many circumstances, though convenient in others. It's >good in those circumstances when the extra array management overhead isn't >needed. It's bad in those circumstances when a C programmer is forced to invent >a more general array data type, such as a structure containing a length and a >pointer to data. Today, I wouldn't think of designing a language without decent >arrays. What I find appealing are two dimensional slice extractions. Even >Ada doesn't have those! The ``Dragon Book'' gives a good discussion for >the representation of arrays such that efficient extractions of rectilinear >sub-arrays portion are possible. But that's all about "good" vs. "bad", which isn't *quite* the same thing as "low level" vs. "high level". My claim is that the C definition of arrays is "low level", as compared to Ada's definition of arrays. I certainly didn't claim that Ada's arrays are at the highest possible level -- after all, they require the index type to be discrete! (We're talking about "level" of abstraction, here, not level of goodness or some such thing.) And I certainly agree that a C struct containing bounds info plus an array (plus associated operations) might be at the same abstraction level as an Ada array. >>4. Array indexing is defined in terms of pointer arithmetic. >>(Well, I admit this is a rather weak reason.) > >These are all weak reasons for the argument that arrays are a low level >construct; they are good reasons for some other claim though, such as the claim >that C arrays are insufficiently general for some purposes. I disagree. An Ada array is more-or-less at the same level of abstraction as a C struct that has bounds plus array components. The plain-old-array, in C, is at a lower level of abstraction. >>5. The lower bound is always zero, rather than whatever makes sense to >>the programmer. E.g. if you want a table that maps the numbers A..B >>onto something-or-other, you have to subtract off A "by hand" > >If you program C long enough, nothing but zero based arrays makes sense! :))) That's the problem with programmers, today. ;-) >>All of the above give me the feeling that a C array is, conceptually, a >>pointer to a hunk of contiguous storage. That's a low-level, >>machine-oriented, notion. > >Except that the elements of that hunk still have a type, possibly a const >qualifier, etc. Granted. It's not quite as low-level as I claimed -- you still have the notion that ptr++ increments by the "right" amount. And you still have const. I.e., granted that ptr++ is not quite as low level as address arithmetic. Hence my caveat on point (4) above. I still stand by the other points. >... The true low level notion in C is that any object can >be treated as though it were an array of characters, and that all storage >is measured in characters. Yeah. That, too. - Bob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` Kaz Kylheku 1997-05-14 0:00 ` Robert A Duff @ 1997-05-14 0:00 ` Kevin Cline 1997-05-14 0:00 ` Robert Dewar 1 sibling, 1 reply; 103+ messages in thread From: Kevin Cline @ 1997-05-14 0:00 UTC (permalink / raw) kaz@vision.crest.nt.com (Kaz Kylheku) wrote: >Today, I wouldn't think of designing a language without decent >arrays. Why? What makes arrays more important that lists or maps? This wss one of my pet peeves with Ada83 -- it provided very nice array support, but nothing else. This just encouraged mediocre Ada programmers to solve every problem with an array, even when another structure would have been considerably faster and easier to use. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-14 0:00 ` Kevin Cline @ 1997-05-14 0:00 ` Robert Dewar 0 siblings, 0 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-14 0:00 UTC (permalink / raw) Kevin says <<Why? What makes arrays more important that lists or maps? This wss one of my pet peeves with Ada83 -- it provided very nice array support, but nothing else. This just encouraged mediocre Ada programmers to solve every problem with an array, even when another structure would have been considerably faster and easier to use.>> I think Ada 83 made the right choice here. It provided the abstraction mechanisms for creating lists and maps, but did not put in direct support, and I think this decision (common for languages at this level) is exactly right. On the other hand, arrays are fundamental, and really need to be there as a primitive. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` Robert A Duff 1997-05-13 0:00 ` Kaz Kylheku @ 1997-05-13 0:00 ` Robert Dewar 1997-05-14 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1 sibling, 1 reply; 103+ messages in thread From: Robert Dewar @ 1997-05-13 0:00 UTC (permalink / raw) Bob Duff said <<4. Array indexing is defined in terms of pointer arithmetic. (Well, I admit this is a rather weak reason.)>> Actually I think that's a bit backwards, I would say that pointer arithmetic in C is defined in terms of indexing in some sense. A pointer in C is conceptually a pair (base address, offset), and pointer arithmetic adjusts the offset, which is closely related to an array index. (indeed it is EXACTLY what COBOL would call an array index :-) But I agree with some of your other reasons, although I do not agree that pointers and arrays are synonymous in C, it is just that there are implicit coercions between these two types. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` Robert Dewar @ 1997-05-14 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 0 siblings, 0 replies; 103+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-05-14 0:00 UTC (permalink / raw) In article <dewar.863575928@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: Bob Duff said <<4. Array indexing is defined in terms of pointer arithmetic. (Well, I admit this is a rather weak reason.)>> Actually I think that's a bit backwards, I would say that pointer arithmetic in C is defined in terms of indexing in some sense. A pointer in C is conceptually a pair (base address, offset), and pointer arithmetic adjusts the offset, which is closely related to an array index. (indeed it is EXACTLY what COBOL would call an array index :-) But I agree with some of your other reasons, although I do not agree that pointers and arrays are synonymous in C, it is just that there are implicit coercions between these two types. From "The C programming language", 2. ed., page 99: "The correspondence between indexing and pointer arithmetic is very close. By definition, the value of a variable or expression of type array is the address of element zero of the array." and further: "In short, an array-and-index expression is equivalent to one written as a pointer and offset" ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` Robert Dewar 1997-05-13 0:00 ` Robert A Duff @ 1997-05-13 0:00 ` David L Brown 1997-05-13 0:00 ` W. Wesley Groleau (Wes) 1997-05-14 0:00 ` Robert Dewar 1 sibling, 2 replies; 103+ messages in thread From: David L Brown @ 1997-05-13 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Bob Duff said > <<I mean, by your reasoning, we shouldn't call Ada's arrays "arrays", > because they might be confused with C arrays, which are a very low-level > notion indeed! ;-) (And, by the way, I have no objection to a language>> > Why are C arrays very low-level notions? > I agree they are often used this way, but I don't see this from the standard. Probably because the notation in C: foo[bar] is semantically equivalent to *(foo + bar) Since addition is commutative, array_name[42] is the same as 42[array_name]. The array notation is just shorthand for pointer arithmetic. Fortunately, you don't have to use it this way. Dave Brown ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` David L Brown @ 1997-05-13 0:00 ` W. Wesley Groleau (Wes) 1997-05-14 0:00 ` Robert Dewar 1 sibling, 0 replies; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-13 0:00 UTC (permalink / raw) Re: Is "_Pointer" an implementation detail or an abstraction? Answer: Depends on how you use it. If neither my algorithm nor my abstraction _depends_ on using a "pointer" or whatever it might be called, then it's an implementation detail. ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` David L Brown 1997-05-13 0:00 ` W. Wesley Groleau (Wes) @ 1997-05-14 0:00 ` Robert Dewar 1 sibling, 0 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-14 0:00 UTC (permalink / raw) David Brown said <<Probably because the notation in C: foo[bar] is semantically equivalent to *(foo + bar)>> Robert replies Actually this is not nearly so "bad" as you might think, as I pointed out in an earlier reply. A pointer in C is a structured value with two parts A reference to the base (in this case the array foo), and an offset in storage units. Pointer arithmetic adjusts the storage unit offset to correspond to the appropriate number of typed components (i.e. in Ada terms component_size is equal to the type'size, and the offset is adjsuted by bar * component_size. So really one could say that *(foo + bar) is simply a shorthand for foo[bar] rather than the other way round! ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert Dewar 1997-05-11 0:00 ` Robert A Duff @ 1997-05-11 0:00 ` John G. Volan 1997-05-12 0:00 ` Kaz Kylheku 2 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-11 0:00 UTC (permalink / raw) Robert Dewar wrote: > > John G. Volan wrote: > > > But once again, I'd want the rule to be simple and minimalistic: Just > > always mark access types (and access objects) with "_Pointer". > > Bad suggestion. Access types are NOT pointers. They may be implemented using > pointers some of the time (but not all the time -- we often find people > using GNAT being surprised to find that access types are not always > represented using simple pointers in some cases, but of course there is > nothing in the language that suggests or requires that access types be > implemented using pointers). I think you're reading too much into my usage of the word "pointer". I did not mean at all to imply any implementation details by using this word, in fact I had in mind exactly the high-level abstraction of an access type. I'm a bit surprised that "pointers" would somehow be a low-level implementation concept. Ever since my Pascal days, I've always viewed them as quite a high level abstraction. Today, with my experience with Ada, I'd tend to use "Address" for the low-level implementation, and indeed, access types are not necessarily simple addresses. Perhaps your interpretation of "pointer" comes from C, where pointers seem to be treated synonymously with addresses. (Although I'm not so sure about that, aren't C pointers sometimes implemented as an address plus an element index?) In fact, the only reason I would suggest this usage would be when you are providing an abstraction that includes both a designated type and a visible access type -- _both_ as part of the visible interface. Both types would relate to the same concept, but they would still need to be differentiated by each other. So one type must be marked somehow. "_Pointer" seems a convenient marker, but if that hits any raw nerves, how about "_Access"? package Targets is type Target_Type is tagged limited private; type Target_Access_Type is access all Target_Type'Class; ... By the way, this would be a case where my naming convention might relax a bit: Not every variable of Target_Access_Type would necessarily have to be called [Optional_Prefix_]Target_Access. The "_Access" could be dropped if you were in a context where you were only working directly with an access variable, and didn't have to have a separate name for the designated object, e.g.: procedure Do_Something_Classwide (Target : in Target_Access_Type); This is especially true if the access type were anonymous: procedure Do_Something_Primitive (Target : access Target_Type); The only time "_Access" would have to be used in an object name would be in (relatively rare) cases where you needed to name both the designated object and the access object in the same scope. The only difficulty with using "Access" as a marker instead of "Pointer" is that "Access", being a reserved word, cannot stand alone as a variable name. When would you want to do that? Consider a generic: generic type Object_Type (<>) is limited private; type Pointer_Type is access all Object_Type; package Garbage_Collected_Refs is -- by convention, let "Ref" mean "Reference" type Ref_Type is private; function "+" (Pointer : in Pointer_Type) return Ref_Type; function "+" (Ref : in Ref_Type) return Pointer_Type; private type Ref_Type is new Controlled with ... end Garbage_Collected_Refs; The first "+" overloading takes an access value and generates a garbage-collected reference value for it, the second retrieves the access value from a reference. At this level of abstraction, we don't have any particular designated type and access type, so there is no compelling reason to mark the access parameter as anything other than "Pointer". If the convention were to use "Access", then we have trouble: generic type Object_Type (<>) is limited private; type Object_Access_Type is access all Object_Type; package Garbage_Collected_Refs -- by convention, let "Ref" mean "Reference" type Ref_Type is private; function "+" (Object_Access : in Object_Access_Type) return Ref_Type; function "+" (Ref : in Ref_Type) return Object_Access_Type; private type Ref_Type is new Controlled with ... end Garbage_Collected_Refs; It might be misleading in this case to take the suggestion I made above and drop "_Access" from the parameter and just call it "Object". These operations are more concerned with the access value rather than the designated object. > Suffixing access types with _Pointer emphasizes the confusion, and seems > inappropriate to me. It is analogous to saying that all integer types > should be suffixed with > > _Twos_Complement_Bit_String > > or somesuch. Reductio ad absurdum at its finest. :-) > Names should be chosen to emphasize the meaning at an > appropriate level of abstraction, not the low-level implementation > dependent representation. Why, I quite agree, and have already said so several times in this discussion. We merely misunderstand each other as to which words refer to abstractions and which to implementation details. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert Dewar 1997-05-11 0:00 ` Robert A Duff 1997-05-11 0:00 ` John G. Volan @ 1997-05-12 0:00 ` Kaz Kylheku 2 siblings, 0 replies; 103+ messages in thread From: Kaz Kylheku @ 1997-05-12 0:00 UTC (permalink / raw) In article <dewar.863365392@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >John G. Volan wrote: > >> But once again, I'd want the rule to be simple and minimalistic: Just >> always mark access types (and access objects) with "_Pointer". > >Bad suggestion. Access types are NOT pointers. They may be implemented using >pointers some of the time (but not all the time -- we often find people You are assuming that a pointer is a lower level construct, that is, a machine address. Whether this is true depends on the context. If an assembly language programmer speaks about pointers, he or she probably means address words. A Pascal programmer might use the word to designate the high level reference type of that language. An access type is basically a pointer. You can say that a URL embedded in someone's web page is also a pointer of sorts. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Aaron Metzger 1997-05-11 0:00 ` Simon Wright 1997-05-11 0:00 ` Robert Dewar @ 1997-05-12 0:00 ` John G. Volan 2 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) Aaron Metzger wrote: > > You really put a different spin on the whole debate with this example. > Up to this point I think people were just expressing different naming > conventions for types and objects in the "problem" space. With > "_Pointer" you are stepping into implementation details. Nope, not at all. See other followups for why "_Pointer" refers to a high-level abstraction. I can be persuaded to substitute it with "_Access" but this just refers to the same high-level abstraction. In Ada83, you may well have been indoctrinated in the idiom that says that access types should be implementation details hidden inside packages. In some cases of abstract data types, that's still quite correct. But object-oriented software tends to get heavy into the use of reference semantics. An "object" (in the OO sense) has an "identity" distinct from its "state". Two objects with the same state are still distinct objects, because their identities are different. Objects tend to cross-reference each other by storing each other's identities (_not_ copying their states). There are many ways such identity references can be implemented, but one very convenient way is with an access type. Therefore, a common object-oriented idiom for Ada95 will be to have a package that implements a notional "class" of objects by declaring a tagged type (preferably limited and private) with an accompanying access type (usually general access to classwide). > Maybe in a > small local scope such conventions won't hurt you too much but I hope > you don't propose suffixes such as _Pointer, (or others that I combat > daily --> _Record, _List, _Array) for any type names that are exposed in > package specs. I can see little justification for marking a type with "_Record", so I agree with you on that. "_List" I would reserve as a marker for some private type (probably from a generic instance) that actually implemented some kind of "list" abstraction. "_Array" I do find to be useful. If an array type is publicly visible in a package spec, I think "_Array" is a perfectly valid marker to put on its name. It tells it like it is: The thing _is_ an "_Array_Type". That's the abstraction clients see: Objects of that type can be indexed and sliced and so forth. Other markers, such as "_Table", "_Vector", "_Matrix", might also be acceptable for a visible array type, but those markers might be even better suited for private types, and anyway, "_Array" just seems more honest. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` John G. Volan 1997-05-10 0:00 ` Aaron Metzger @ 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` John G. Volan ` (2 more replies) 1997-05-10 0:00 ` Kaz Kylheku ` (2 subsequent siblings) 4 siblings, 3 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-10 0:00 UTC (permalink / raw) In my programming the name clash that I most often come across is something like Parent : constant xxx := Parent (K); now of course I don't want to use the same name in both places here, and I have not really settled on a convention. I don't like The_Parent, because I find The_ too much noise. Often I use an abbreviation if the scope is very small, something like Parnt : constant xxx := Parent (K); I know that some coders and some coding standards are allergic to abbreviations, but I don't mind short identifiers and abbreviations if they have a small local scope. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Robert Dewar @ 1997-05-10 0:00 ` John G. Volan 1997-05-11 0:00 ` Robert Dewar 1997-05-11 0:00 ` Kevin Cline 1997-05-14 0:00 ` Ben Brosgol 2 siblings, 1 reply; 103+ messages in thread From: John G. Volan @ 1997-05-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In my programming the name clash that I most often come across is something > like > > Parent : constant xxx := Parent (K); Just out of curiosity, what is "K"? "Key"? "Kid"? "Kludge"? :-) > now of course I don't want to use the same name in both places here, and > I have not really settled on a convention. I don't like The_Parent, because > I find The_ too much noise. I used to be of the school of thought that a function name should be a noun phrase (possibly including the name of the type being returned, although this need not be rigorous). But one inevitably bumps into this very name clash: The tendency is to want to use the same noun for the object receiving the result of the function. My conclusion was to give up on trying to use pure noun phrases for function names, and instead find a way to mark the function names. Booch seems to prefer using a dangling preposition that leads into the parameters: function Parent_Of (Child : in Pointer_Type) return Pointer_Type; ... Parent : Pointer_Type := Parent_Of(Child); But I've found this to be awkward sometimes, particularly when the function has more than one parameter. Is it necessarily the first parameter that is the object of the preposition? Sometimes the most natural prepositional phrase in English wants a "secondary" parameter as its prepositional object and not the "primary" (i.e. controlling) parameter of the function, so you're forced into contortions just to satisfy English. An alternative that I've personally settled on is to give up on the distinction between functions and procedures, and to simply use verb phrases for all subprogram names. This emphasizes to the reader that there is always _something_ happening when you make a subprogram call, and the programmer should keep in mind the cost of making the call. Even when it's a function without side effects, there is the cost of whatever calculation or retrieval it's performing. And even if that cost is inlined and optimized away, there is at least a hypothetical cost -- which might not be so hypothetical if there is a design change during maintenance and the function must be implemented differently. If no particular verb comes to mind, a function could just tack on "Get_" as a default: function Get_Parent (Child : in Pointer_Type) return Pointer_Type; procedure Set_Parent (Child : in out Pointer_Type; Parent : in Pointer_Type); ... Parent : Pointer_Type := Get_Parent(Child); Note that there is a nice symmetry between a procedure that sets a value and a function that gets it. This convention has some precedents in the naming styles I've seen in code written in other languages, and I see no reason to denigrate this. > Often I use an abbreviation if the scope is > very small, something like > > Parnt : constant xxx := Parent (K); > > I know that some coders and some coding standards are allergic to > abbreviations, but I don't mind short identifiers and abbreviations if > they have a small local scope. It's against my religion to give up on the "Thou shalt not abbreviate" commandment so easily. :-) Where do you draw the line on what counts as a "small" scope? Small scopes can have a nasty tendency to grow with time. I mean, it's sort of like saying that it's bad to beat up somebody on a crowded street, but it's okay to beat up your spouse as long as you do it in the privacy of your own home... hmm, I was going to put a smiley in there, but that's just not funny. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` John G. Volan @ 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-11 0:00 UTC (permalink / raw) John asks <<Robert Dewar wrote: > > In my programming the name clash that I most often come across is something > like > > Parent : constant xxx := Parent (K); Just out of curiosity, what is "K"? "Key"? "Kid"? "Kludge"? :-)>> K is just an abbreviation for some expression which is not important in this example. <<It's against my religion to give up on the "Thou shalt not abbreviate" commandment so easily. :-) Where do you draw the line on what counts as a "small" scope? Small scopes can have a nasty tendency to grow with time.>> I notice again you using the term religeon. I strongly advise an agnostic viewpoint when it comes to programming. Religeously inspired rules and views tend to be a menace when it comes to programming style. I understand the comfort of letting rules substitute for judgment, but I think it is a bad idea to have any absolute rules (except this self referential one :-) <<If no particular verb comes to mind, a function could just tack on "Get_" as a default: function Get_Parent (Child : in Pointer_Type) return Pointer_Type; procedure Set_Parent (Child : in out Pointer_Type; Parent : in Pointer_Type); ...>> Well as you know well if you have looked at the GNAT sources, the Get_ and Set_ prefixes are extensively used, but again, I think it is a mistake to take a religeously consistent view here. The fundamental tree walking functions Next, Prev, and Parent are used *so* extensively that choosing any other names for them would add unnecessary obfuscatory expansion to the code. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert Dewar @ 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > > John asks > > <<It's against my religion to give up on the "Thou shalt not abbreviate" > commandment so easily. :-) > > I notice again you using the term religeon. I strongly advise an agnostic > viewpoint when it comes to programming. Religeously inspired rules and > views tend to be a menace when it comes to programming style. You of course noted my smiley there, right? ... :-) I knew this discussion would arouse some strong emotions and challenge some cherished habits, so I deliberately sought to defuse the situation in advance with a bit of humor in the subject line... > I understand > the comfort of letting rules substitute for judgment, but I think it is a > bad idea to have any absolute rules (except this self referential one :-) Every rule has a domain of applicability, beyond which it becomes oppressive. But within its domain of applicability, I do not see why it should not be absolute. Rigor can reap great benefits. The exercise of applying a rule rigorously can sometimes, just by itself, crystallize a person's thinking and reveal flaws in a design. Where judgment should come into play is knowing where the bounds of a rule's domain extend. In this discussion, I have been trying to push the bounds outward a bit, to challenge what I perceive as loose thinking. Perhaps in some cases the bounds have been stretched too far and must be pulled back. If so, it is not going to be satisfying to me if the rationale for tightening the bounds is simply "we're not used to it" or "just doesn't _feel_ right." It is much more satisfying to me if the rationale is based on some higher order rule freshly discovered, leading to even greater comprehension. As for comfort, comfort was not one of my primary goals in devising a naming convention. Reducing the mental workload for the author and the readers was. Simple rules rigorously applied can eliminate unnecessary work at a lower level and leave energy available for higher-order problems. Also, I believe keeping to Engish reduces work in the long run. I cling to English words wherever I can simply because of English's universal utility: English is the one constant I can guarantee that all readers will be immediately familiar with, at all times, in all contexts. (That's not jingoism, it's just reality: for better or worse, this is an Engish-speaking world.) > Well as you know well if you have looked at the GNAT sources, the > Get_ and Set_ prefixes are extensively used, Haven't looked, not recently anyway. But "Get_" and "Set_" have ample precedent elsewhere. > but again, I think it > is a mistake to take a religeously consistent view here. Again, it's not religion, but rather a drive for rigor. > The > fundamental tree walking functions Next, Prev, and Parent are > used *so* extensively that choosing any other names for them > would add unnecessary obfuscatory expansion to the code. I do not dispute your choice to reserve simple unmarked words for use in naming these functions, but it does mean that those identifiers become unavailable for the recipient objects. The latter must then be marked in some way. That's an acceptable trade-off. I'm just a bit disappointed that the way you chose to mark them involved devising ad hoc abbreviations on the spot. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan @ 1997-05-12 0:00 ` Robert I. Eachus 1997-05-13 0:00 ` John G. Volan 1997-05-13 0:00 ` Robert Dewar 1 sibling, 2 replies; 103+ messages in thread From: Robert I. Eachus @ 1997-05-12 0:00 UTC (permalink / raw) In article <dewar.863324701@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: Robert Dewar said: > In my programming the name clash that I most often come across > is something like > Parent : constant xxx := Parent (K); My reaction in those cases is to diagnose a misplaced use clause, and use the package name: Parent : constant xxx := My_List_Instance.Parent (K); If this is not sufficient, you have a deeper design problem. It may be possible to call a function in the scope in which it is defined without ABE in this case in Ada 95: function Parent(Foo: Bar) return xxx is... end Parent; Parent: constant xxx := My_List_Instance.Parent (K); ...but most such cases are very suspicious. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` Robert I. Eachus @ 1997-05-13 0:00 ` John G. Volan 1997-05-13 0:00 ` Robert Dewar 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-13 0:00 UTC (permalink / raw) Robert I. Eachus wrote: > > In article <dewar.863324701@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > Robert Dewar said: > > > In my programming the name clash that I most often come across > > is something like > > Parent : constant xxx := Parent (K); > > My reaction in those cases is to diagnose a misplaced use clause, That's not the only way this could happen. We might have a subsystem of child packages. A subprogram that has widespread utility within the subsystem might be declared high up in a root package, and a code snippet like this could be located down in a child package. Visibility to the contents of the root package comes for free, without any need for a use-clause. Would such an arrangement be "misplaced"? I wouldn't think so, I'd view it as a conscious design decision. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` Robert I. Eachus 1997-05-13 0:00 ` John G. Volan @ 1997-05-13 0:00 ` Robert Dewar 1997-05-16 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 103+ messages in thread From: Robert Dewar @ 1997-05-13 0:00 UTC (permalink / raw) iRobert Eachus says << My reaction in those cases is to diagnose a misplaced use clause, and use the package name: Parent : constant xxx := My_List_Instance.Parent (K);>> Well you sure take a shaky place to make the no-use-clause stand. I find it hard to imagine that anyone would think that it made the GNAT soures clearer to do a global replace of Parent with Atree.Parent. Given that the whole of GNAT is about tree processing, and the Parent function is truly fundamental, this seems silly to me. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` Robert Dewar @ 1997-05-16 0:00 ` Robert I. Eachus 1997-05-17 0:00 ` Robert Dewar 0 siblings, 1 reply; 103+ messages in thread From: Robert I. Eachus @ 1997-05-16 0:00 UTC (permalink / raw) In article <dewar.863496133@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: (I said:) >> My reaction in those cases is to diagnose a misplaced use clause, >> and use the package name: >> Parent : constant xxx := My_List_Instance.Parent (K);>> RBKD said: > Well you sure take a shaky place to make the no-use-clause > stand. I find it hard to imagine that anyone would think that it > made the GNAT soures clearer to do a global replace of Parent > with Atree.Parent. Given that the whole of GNAT is about tree > processing, and the Parent function is truly fundamental, this > seems silly to me. I wasn't advocating elimination of use clauses, and I never have. I tend to be a moderate on the subject. (Look at my .sig file! ;-) But in this case, there is a perfectly simple "fix" of the problem by adding the needed qualification. The reason for the reference to misplaced use clauses was because I'll look there to see what the right prefix is. Incidently, and here I am willing to be counted as an extremist, often the right solution to use cause induced conflicts is to put the use clauses where needed, rather than in the context clause. If you have 20 operations on an ADT, two of which use Text_IO, put a with Text_IO in the context clause for the body, but put the use clauses in the IO operations. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-16 0:00 ` Robert I. Eachus @ 1997-05-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-17 0:00 UTC (permalink / raw) Robert Eachus said << Incidently, and here I am willing to be counted as an extremist, often the right solution to use cause induced conflicts is to put the use clauses where needed, rather than in the context clause. If you have 20 operations on an ADT, two of which use Text_IO, put a with Text_IO in the context clause for the body, but put the use clauses in the IO operations.>> But you are talking in generalities, responding to my very specific example. You cannot seriously be suggesting that in the GNAT sources, for the hundreds, even thousands, of references to Parent, that we put a use clause in for each of them, and anyway, I don't even see that putting a use clause in is relevant in this case. Your only proferred solution that seems to work is Parent : constant Node_Id := Nlists.Parent (Other_Node); But I find the Nlists. here all over the place to be nasty noise, and of course you cannot eliminate this Nlists. with a use clause, since then you have the name conflict. Please note that this is no big deal. Very often we are talking about tiny routines where P : constant Node_Id := Parent (Other_Node); is quite fine. As many people have noted, short variable names, even one letter names, are quite fine if they are very local. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` John G. Volan @ 1997-05-11 0:00 ` Kevin Cline 1997-05-11 0:00 ` Robert Dewar 1997-05-16 0:00 ` Wayne Magor 1997-05-14 0:00 ` Ben Brosgol 2 siblings, 2 replies; 103+ messages in thread From: Kevin Cline @ 1997-05-11 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >In my programming the name clash that I most often come across is something >like > > Parent : constant xxx := Parent (K); > >now of course I don't want to use the same name in both places here, and >I have not really settled on a convention. I don't like The_Parent, because >I find The_ too much noise. Often I use an abbreviation if the scope is >very small, something like > > Parnt : constant xxx := Parent (K); > >I know that some coders and some coding standards are allergic to >abbreviations, but I don't mind short identifiers and abbreviations if >they have a small local scope. > I think this is an important point. For identifiers that have small scope, almost any name will do if it has some mnemonic value. Because I don't like to even remember which abbreviation was chosen, I use single letter variable names for temporaries in small functions whenever possible. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Kevin Cline @ 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan 1997-05-16 0:00 ` Wayne Magor 1 sibling, 1 reply; 103+ messages in thread From: Robert Dewar @ 1997-05-11 0:00 UTC (permalink / raw) <<I think this is an important point. For identifiers that have small scope, almost any name will do if it has some mnemonic value. Because I don't like to even remember which abbreviation was chosen, I use single letter variable names for temporaries in small functions whenever possible.>> For me that goes too far, I have seen far too much code with cryptic one letter identifiers like D, where short names would have helped a lot (something like Depth). Interestingly, I note that this preference for one letter identifiers often seems to go along with an allergy to writing comments. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert Dewar @ 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > > <<I think this is an important point. For identifiers that have small scope, > almost any name will do if it has some mnemonic value. Because I don't like > to even remember which abbreviation was chosen, I use single letter variable > names for temporaries in small functions whenever possible.>> > > For me that goes too far, I have seen far too much code with cryptic > one letter identifiers like D, where short names would have helped a > lot (something like Depth). Interestingly, I note that this preference > for one letter identifiers often seems to go along with an allergy to > writing comments. Robert, can you see how your relaxed attitude towards small scopes can be abused by other programmers, and lead us down this slippery slope? I have been trying to make a distinction between two different kinds of abbreviations: (1) conventional abbreviations, which are established at a project level, documented, and used consistently and universally; and (2) ad hoc abbreviations, which are invented on the spot, idiosyncratic, and inconsistent. Often times, one engineer will choose one ad hoc abbreviation and another will choose and entirely different one -- for the same concept! Chaos! ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` John G. Volan @ 1997-05-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-12 0:00 UTC (permalink / raw) John says <<Robert, can you see how your relaxed attitude towards small scopes can be abused by other programmers, and lead us down this slippery slope? >> Indeed. Almost all my suggestions, and anyone else's for that matter can be abused. My solution to that is not to imagine that abuse can be prevented by over fanatic application of arbitrary rules, my solution is to get rid of abusive programmers, either by removal or education! ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Kevin Cline 1997-05-11 0:00 ` Robert Dewar @ 1997-05-16 0:00 ` Wayne Magor 1997-05-16 0:00 ` Robert Dewar 1997-05-16 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan 1 sibling, 2 replies; 103+ messages in thread From: Wayne Magor @ 1997-05-16 0:00 UTC (permalink / raw) clines@delete_this.airmail.net (Kevin Cline) writes: > >dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >> >>I know that some coders and some coding standards are allergic to >>abbreviations, but I don't mind short identifiers and abbreviations if >>they have a small local scope. > >I think this is an important point. For identifiers that have small scope, >almost any name will do if it has some mnemonic value. Because I don't like >to even remember which abbreviation was chosen, I use single letter variable >names for temporaries in small functions whenever possible. Good point. It is a matter of degree and scope. Single letter variable names are very appropriate in certain contexts. For example, I use them extensively as FOR loop variables, since it usually has no meaning other than to count which iteration we are on. Using long names too often can actually make code *harder* to read. We are already deluged with so many concepts, classes, and structures that we don't need to clutter things by naming unimportant items. The reader's attention should be focused on what is important. Those are what deserve good (possibly long) names. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-16 0:00 ` Wayne Magor @ 1997-05-16 0:00 ` Robert Dewar 1997-05-18 0:00 ` Nick Roberts 1997-05-20 0:00 ` naming convention discussion Peter Hermann 1997-05-16 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan 1 sibling, 2 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-16 0:00 UTC (permalink / raw) Wayne says <<Good point. It is a matter of degree and scope. Single letter variable names are very appropriate in certain contexts. For example, I use them extensively as FOR loop variables, since it usually has no meaning other than to count which iteration we are on.>> Certainly that's reasonable for small loops. However in the GNAT style standards, we do not permit the use of the variable I, since in a sans-serif font, it is too easily mixed up with the digit 1. The single letter O is a bad choice for similar reasons. (amusing completely irrelevant anecdote. This morning I called up UA and asked them to locate a record, I gave the locator as Tango-Zero-Echo-Echo-Boy-Queen The agent couldn't find it ... she was looking for T0EEBQ my locator was TZEEBQ :-) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-16 0:00 ` Robert Dewar @ 1997-05-18 0:00 ` Nick Roberts 1997-05-20 0:00 ` naming convention discussion Peter Hermann 1 sibling, 0 replies; 103+ messages in thread From: Nick Roberts @ 1997-05-18 0:00 UTC (permalink / raw) Are we avoiding 'Zulu' for P. C. reasons? Nick ;-) ^ permalink raw reply [flat|nested] 103+ messages in thread
* naming convention discussion 1997-05-16 0:00 ` Robert Dewar 1997-05-18 0:00 ` Nick Roberts @ 1997-05-20 0:00 ` Peter Hermann 1 sibling, 0 replies; 103+ messages in thread From: Peter Hermann @ 1997-05-20 0:00 UTC (permalink / raw) Robert Dewar (dewar@merv.cs.nyu.edu) wrote: > (amusing completely irrelevant anecdote. This morning I called up UA and UA? > asked them to locate a record, I gave the locator as > Tango-Zero-Echo-Echo-Boy-Queen > The agent couldn't find it ... > she was looking for T0EEBQ > my locator was TZEEBQ > :-) which is spelled: tango zulu echo echo bravo quebec BTW: zero still keeps to be zero: she was correct :-) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-16 0:00 ` Wayne Magor 1997-05-16 0:00 ` Robert Dewar @ 1997-05-16 0:00 ` John G. Volan 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-16 0:00 UTC (permalink / raw) Wayne Magor wrote: > > We > are already deluged with so many concepts, classes, and structures that > we don't need to clutter things by naming unimportant items. This is a curious statement. There are very few things that can be declared anonymously in Ada. Generally, if you're declaring it, you have to give it _some_ identifier. How do you propose to get away with _not_ naming something? :-) Well, if what you really meant was that you want to give some things cryptic short names, in an effort to reduce the client's mental overload in dealing with the complexity of your software, I'd say you're fooling yourself -- at best, that's a bandaid approach to complexity. If you want to reduce the number of details that a user has to understand, use _abstraction_. Wrap the darn thing in a package. Wrap the types up as private types. Hide the more arcane details in the body/private part. Provide a streamlined interface. Reduce coupling, increase cohesion. Yada, yada, yada... how often is this litany professed, yet never _really_ understood, and carried out? :-) > Using long names too often can actually make code *harder* to read. ... > The reader's > attention should be focused on what is important. Those are what deserve > good (possibly long) names. Names don't have to be "long" to be "good." The shorter the better, I say -- within limits, and for me those limits are English. There's an art to picking short, but meaningful names. But there's still the problem of distributing the same short meaningful name to several program entities that all "want" that same name. Some kind of systematic "noise" has to be attached to get different identifiers. If you're saying that this "noise" should be shortened to the bare minimum, at all costs, well okay, I'll buy that. Maybe you'd prefer: Project Convention: "_T" shall be the universal type-marking suffix type Target_T is ... -- a "target" is the weapon system's hypothesis of some -- real object flying out there procedure Create (Target : in out Target_T); procedure Assess_Threat (Target : in out Target_T); procedure Engage_Attack (Target : in out Target_T); ... type Track_T is ... -- a "track" is a sensor phenomenon; several tracks might be -- associated with the same hypothesized target procedure Create (Track : in out Track_T); procedure Update (Track : in out Track_T); As opposed to the barbarous: type Target is ... -- a "target" is the weapon system's hypothesis of some -- real object flying out there procedure Create (Trg : in out Target); -- Abe wrote this procedure Assess_Threat (Targ : in out Target); -- Becky wrote this procedure Engage_Attack (Tgt : in out Target); -- Chris wrote that ... type Track is ... -- a "track" is a sensor phenomenon; several tracks might be -- associated with the same hypothesized target procedure Create (Trk : in out Track); -- Abe wrote this procedure Update (Trac : in out Track); -- Becky wrote that Or the truly horrendous, but all too tempting: type Target is ... -- a "target" is the weapon system's hypothesis of some -- real object flying out there procedure Create (T : in out Target); procedure Assess_Threat (T : in out Target); procedure Engage_Attack (T : in out Target); ... type Track is ... -- a "track" is a sensor phenomenon; several tracks might be -- associated with the same hypothesized target procedure Create (T : in out Track); procedure Update (T : in out Track); At what point will our pour befuddled maintenance engineer start confusing "T" for a Track with "T" for a Target? ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` John G. Volan 1997-05-11 0:00 ` Kevin Cline @ 1997-05-14 0:00 ` Ben Brosgol 1997-05-14 0:00 ` naming convention: trailing underscore Peter Hermann [not found] ` <dewar.863717431@merv> 2 siblings, 2 replies; 103+ messages in thread From: Ben Brosgol @ 1997-05-14 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In my programming the name clash that I most often come across is something > like > > Parent : constant xxx := Parent (K); > > now of course I don't want to use the same name in both places here, and > I have not really settled on a convention. I don't like The_Parent, because > I find The_ too much noise. Often I use an abbreviation if the scope is > very small, something like > > Parnt : constant xxx := Parent (K); Here's a modest proposal for Ada 0Y that will solve this problem: allow an identifier to include a single trailing underscore. That way you could write: Parent_ : constant xxx := Parent (K); with a minimum of notational overhead. Too bad nobody thought of this idea for Ada 9X :-) :-) Ben Brosgol Aonix brosgol@aonix.com ^ permalink raw reply [flat|nested] 103+ messages in thread
* naming convention: trailing underscore 1997-05-14 0:00 ` Ben Brosgol @ 1997-05-14 0:00 ` Peter Hermann 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Michael F Brenner [not found] ` <dewar.863717431@merv> 1 sibling, 2 replies; 103+ messages in thread From: Peter Hermann @ 1997-05-14 0:00 UTC (permalink / raw) Ben Brosgol (brosgol@world.std.com) wrote: : Here's a modest proposal for Ada 0Y that will solve this problem: allow Do we all accept "Ada 0Y" as official project name for Ada 2007? : an identifier to include a single trailing underscore. That way you : could write: : Parent_ : constant xxx := Parent (K); I strongly disagree. This topic has been discussed in leeength... : Too bad nobody thought of this idea for Ada 9X :-) :-) two smileys acknowledged -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention: trailing underscore 1997-05-14 0:00 ` naming convention: trailing underscore Peter Hermann @ 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Michael F Brenner 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-14 0:00 UTC (permalink / raw) Ben Brosgol (brosgol@world.std.com) wrote: > > Here's a modest proposal for Ada 0Y that will solve this problem: allow > an identifier to include a single trailing underscore. That way you > could write: > > Parent_ : constant xxx := Parent (K); Gadzooks! Get thee behind me, Satan! :-) :-) What were we saying about religion? :-) :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention: trailing underscore 1997-05-14 0:00 ` naming convention: trailing underscore Peter Hermann 1997-05-14 0:00 ` John G. Volan @ 1997-05-15 0:00 ` Michael F Brenner 1 sibling, 0 replies; 103+ messages in thread From: Michael F Brenner @ 1997-05-15 0:00 UTC (permalink / raw) If we did, we would be giving bad example of how to handle the Year 2000 problem in all who saw it. Everyone knows that there was no leap year in the year 0, but there is in the year 00. THerefore, to prevent people from thinking that they will fix the problem by keeping their two-digit years, we should write it out Ada-200x. Otherwise, people might think there was a data-overflow in Ada :). ^ permalink raw reply [flat|nested] 103+ messages in thread
[parent not found: <dewar.863717431@merv>]
* naming convention discussion [not found] ` <dewar.863717431@merv> @ 1997-05-16 0:00 ` Peter Hermann 1997-05-16 0:00 ` Robert Dewar 1997-05-16 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Robert A Duff 1997-05-17 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Arthur Schwarz 2 siblings, 1 reply; 103+ messages in thread From: Peter Hermann @ 1997-05-16 0:00 UTC (permalink / raw) Robert Dewar (dewar@merv.cs.nyu.edu) wrote: > But on the final vote, the French delegation in particular made a major > issue of opposing this, and insisted on its deletion, so it was deleted. > They felt it encouraged bad identifiers such as A__________________B, > which is horrible, indeed, though not much worse than OOOOOOOOOOOOO0000OOOO > and no one has yet proposed a rule to somehow eliminate the ability to > write the latter (or for that matter a simple syntactic rule which would > make it imopssible to choose bad identifier names :-) "bad" is relative. We designed a finite element code (still running) for computation of dynamical structural problems. The user of our system could deliver fortran code fragments to be called by our system, the so-called excitiation functions, subject to be frequently called e.g. for math. integration, etc. . This was accomplished by reading his statements and generating wrapping fortran functions, compiling them, and binding them in the next major step on OS-level, of course. The potential name clashes' problem was solved by chosing unlikely names like O00O0O for real variables and I0OO0O for integer variables in the same scope of the users' variables. The project part within the system was "O0NUFU" (numerical functions spoiled) and the teamers still tease me for that name ;-) -- I cannot accept any superfluous constraint upon the choice of names. -- with excess experience on portability/maintenance/linkers/OSs in mind, I am reluctant to allow trailing underscores in identifiers: They open several cans of worms. BTW, the dynamic updating process of software upon a running process should be emphasized in Ada200x (I have the Mars mission in mind), IMHO. With Robert de War in mind, I am putting my flame suit on. :-) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention discussion 1997-05-16 0:00 ` naming convention discussion Peter Hermann @ 1997-05-16 0:00 ` Robert Dewar 1997-05-20 0:00 ` Peter Hermann 0 siblings, 1 reply; 103+ messages in thread From: Robert Dewar @ 1997-05-16 0:00 UTC (permalink / raw) Peter Herman said << I am reluctant to allow trailing underscores in identifiers: They open several cans of worms.>> (did you say this, I was a little unclear, it was indented like a quote, but no signs of a quote>> I don't understand what cans of worms would be opened by this feature ... ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention discussion 1997-05-16 0:00 ` Robert Dewar @ 1997-05-20 0:00 ` Peter Hermann 0 siblings, 0 replies; 103+ messages in thread From: Peter Hermann @ 1997-05-20 0:00 UTC (permalink / raw) > Peter Herman said > I am reluctant to allow trailing underscores in identifiers: > They open several cans of worms. Robert Dewar (dewar@merv.cs.nyu.edu) wrote: > I don't understand what cans of worms would be opened by this feature ... Apart from the standard software as used by the majority, there happens to exist everywhere(IMHO!) software doing some work of editors, browsers, linkers, maintenance tools, program development environments, little chunks of software, small tools, home brewn examination programs, etc. for which the "normal" appearance of a variable is just accepted with a minimum of effort as a token/name_nail/ etc. -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] [not found] ` <dewar.863717431@merv> 1997-05-16 0:00 ` naming convention discussion Peter Hermann @ 1997-05-16 0:00 ` Robert A Duff 1997-05-18 0:00 ` Underscores in identifiers (was: Warning: Religious naming convention discussion :-) Ben Brosgol 1997-05-17 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Arthur Schwarz 2 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 1997-05-16 0:00 UTC (permalink / raw) In article <dewar.863717431@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >This proposal was unanimously accepted at the DR/WG9 meeting the South of >England in the forest (I forgot the name :-) My memory is *slightly* different: There were three separate votes taken (which I thought was silly), on three separate issues. Whether to allow (1) leading underscores, (2) two underscores in a row, or (3) trailing underscores. To my astonishment, the votes came out different. I'm not too sure, but I think (2) lost by a little bit, (1) lost by a greater margin, and (3) won by a little bit. So the design team published the next version of the document allowing (3). However, this annoyed some people greatly. It was more than just the French delegation. So, although I had been in favor of free use of underscores, I pushed on Tucker to go back to the Ada 83 rule, because (A) I thought that it was ludicrous to change the rule, but not change it fully, and (B) although the split was roughly 50-50, the people against trailing underscores felt much more strongly (fanatically, I would say!) than the other side, so we shouldn't piss people off over such an unimportant feature. So we proposed this at the next meeting, and that's the way it ended up. I can't remember the name of the forest, either. :-) >Anyway, there you are -- it's not in Ada 95 (you can guess which side >Robert_ Dewar_ was_ supporting_ :-) I was on the same side as Robert. The really annoying thing is that we were trying to have a good interface to C, and *leading* underscores would come in really handy, there. I suppose the design team could have insisted on having our way, but we wanted to save our insisting for cases we felt were important enough to go against the majority opinion. - Bob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Underscores in identifiers (was: Warning: Religious naming convention discussion :-) 1997-05-16 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Robert A Duff @ 1997-05-18 0:00 ` Ben Brosgol 0 siblings, 0 replies; 103+ messages in thread From: Ben Brosgol @ 1997-05-18 0:00 UTC (permalink / raw) Robert A Duff wrote: > ... There were three separate votes taken > (which I thought was silly), on three separate issues. Whether to allow > (1) leading underscores, (2) two underscores in a row, or (3) trailing > underscores. To my astonishment, the votes came out different. I'm not > too sure, but I think (2) lost by a little bit, (1) lost by a greater > margin, and (3) won by a little bit. So the design team published the > next version of the document allowing (3). However, this annoyed some > people greatly. It was more than just the French delegation. So, > although I had been in favor of free use of underscores, I pushed on > Tucker to go back to the Ada 83 rule, because (A) I thought that it was > ludicrous to change the rule, but not change it fully, and (B) although > the split was roughly 50-50, the people against trailing underscores > felt much more strongly (fanatically, I would say!) than the other side, > so we shouldn't piss people off over such an unimportant feature. So we > proposed this at the next meeting, and that's the way it ended up. > ... > >Anyway, there you are -- it's not in Ada 95 (you can guess which side > >Robert_ Dewar_ was_ supporting_ :-) > > I was on the same side as Robert. The really annoying thing is that we > were trying to have a good interface to C, and *leading* underscores > would come in really handy, there. > > I suppose the design team could have insisted on having our way, but we > wanted to save our insisting for cases we felt were important enough to > go against the majority opinion. > > - Bob Let me add my recollections, since I guess I'm responsible for stirring up the pot here with my earlier article. At one point in the Ada 9X design (I think this was in mid '93 or so) we had reached a grudging compromise allowing an identifier to include a single trailing underscore. Just as the embers of this issue were dying down, a member of the design team, Offer Pazy, came along with a figurative can of gasoline and sent out a message to the reviewers to the effect that allowing identifiers to end with an underscore was a violation of fundamental Ada design principles, or something to that effect. (Offer, if you're out there and reading this, you can confirm or deny this point.) In any event, there's nothing like an argument about lexical or syntactic issues to get people's language designer juices flowing -- some would be amazed at how much time was spent at the Villars WG9 meeting (March '94) before settling on "Adjust" for the name of the procedure that is invoked during assignment for a controlled type -- and it wasn't long before it was obvious that the "compromise" solution for a single trailing underscore was unraveling. As Bob mentioned in the quote above, the dynamic was that noone felt passionatley in favor of allowing more generality for underscores in identifiers, but at least one delegation (and I think others as well) felt _extremely_ strongly that such liberalization would seriously compromise program readability. So back to the Ada 83 identifier rules we reverted. Ben Brosgol brosgol@aonix.com ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] [not found] ` <dewar.863717431@merv> 1997-05-16 0:00 ` naming convention discussion Peter Hermann 1997-05-16 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Robert A Duff @ 1997-05-17 0:00 ` Arthur Schwarz 1997-05-17 0:00 ` Robert Dewar 2 siblings, 1 reply; 103+ messages in thread From: Arthur Schwarz @ 1997-05-17 0:00 UTC (permalink / raw) Robert Dewar wrote: > > iBen wrote, with smileys > > <<Here's a modest proposal for Ada 0Y that will solve this problem: allow > England in the forest (I forgot the name :-) Had to be 'Sherwood' - robbing from the poor and giving to the rich :-) > > But on the final vote, the French delegation in particular made a major > issue of opposing this, and insisted on its deletion, so it was deleted. > They felt it encouraged bad identifiers such as A__________________B, > which is horrible, indeed, though not much worse than OOOOOOOOOOOOO0000OOOO The contention that underscores undermine any naming characterization is ludicrous. As you pointed out above, it is just as possible to generate ridiculous names using existing conventions. So what was really sticking in the craw of the French? art ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-17 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Arthur Schwarz @ 1997-05-17 0:00 ` Robert Dewar 1997-05-17 0:00 ` John G. Volan 0 siblings, 1 reply; 103+ messages in thread From: Robert Dewar @ 1997-05-17 0:00 UTC (permalink / raw) art said <<The contention that underscores undermine any naming characterization is ludicrous. As you pointed out above, it is just as possible to generate ridiculous names using existing conventions. So what was really sticking in the craw of the French?>> Well -- I see my style in denouncing things as ludicrous is catching :-) Actually, it was the French who lead the charge here, but they had sympathizers in other delegations :-) To be fair, the underscores are a little more of a problem consider a__________b and a0000000000b and now imagine that we were not using a junk monospaced font (one of the less attractive inventions of the computer age). Then we would be completely unable to tell how many underlines are there. Still, over all, I have to agree with the use of the "L" word here :-) P.S. A little anecdote about the use of the "L" word. We were at an ARG meeting, and Jean and I always use to argue ferociously -- so much so that some Americans were quite surprised to learn that we are, now, then and earlier, very good friends -- Americans always have trouble distinguishing argument from quarrelling :-) At one point, Jean got up and said "Ah, now I see thinks more clearly, now that Robert has said my position is ludicrous nonsense, I see that I must be completely wrong!" A most charming way of complaining about excessive rhetoric. We all laughed and continued the discussion at a more constructive level :-) By the way, the word argument is interesting. In England it tends to have much more positive connotations. I was always brought up to consider argument as a valuable method for intellectual exploration (for more on this see my father's autobiography -- Michael J.S. Dewar in the ACS autobiography series). On the other hand, in the US, people tend to equate argument with quarrelling, and find it hard not to argue without getting emotionally involved. I have a good principle on argument. Never argue a position unless you are willing to argue the other side. If you are not willing to argue he other side then eitther (a) you are too emotionally involved (b) you don't understand the other side well enough Either reason is good enough to avoid arguing the point. Once John Goodenough and I planned a debate on some Ada related subject, where the deal was we would toss a coin just before the debate to see who took what side, to emphasize this principle, but it never materialized :-) Of course another trouble is that if you do argue both sides, then people get confused -- "but I thought you believed ...." To me, belief is about religeon, and is better excluded from technical discussions about programming languages -- none of the issues we talk about is important enough to invest emotional commitment and religeous belief in them :-) Robert ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-17 0:00 ` Robert Dewar @ 1997-05-17 0:00 ` John G. Volan 1997-05-18 0:00 ` Andrew Dunstan 0 siblings, 1 reply; 103+ messages in thread From: John G. Volan @ 1997-05-17 0:00 UTC (permalink / raw) This might be a bit off-topic, but... Robert Dewar wrote: > > Of course another trouble is that if you do argue both sides, then people > get confused -- "but I thought you believed ...." To me, belief is about > religeon, ^^^^^^^^ > and is better excluded from technical discussions about programming > languages -- none of the issues we talk about is important enough to invest > emotional commitment and religeous belief in them :-) ^^^^^^^^^ ... this has been nagging at me: are "religeon" and "religeous" British spellings for "religion" and "religious"? Just curious... :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-17 0:00 ` John G. Volan @ 1997-05-18 0:00 ` Andrew Dunstan 1997-05-18 0:00 ` Nick Roberts 0 siblings, 1 reply; 103+ messages in thread From: Andrew Dunstan @ 1997-05-18 0:00 UTC (permalink / raw) John G. Volan (johnvolan@sprintmail.com) wrote: : This might be a bit off-topic, but... [snip] : ... this has been nagging at me: are "religeon" and "religeous" British : spellings for "religion" and "religious"? Just curious... :-) not according to my SOED :-) cheers andrew -- ------------------------------------------------------------------------- There's nothing either good or bad, but thinking makes it so - Hamlet http://www.gr-lakes.com/~andrew (including PGP key) PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE 3D 11 FA 15 4D 87 1F 5E ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-18 0:00 ` Andrew Dunstan @ 1997-05-18 0:00 ` Nick Roberts 1997-05-19 0:00 ` John G. Volan 1997-05-19 0:00 ` John G. Volan 0 siblings, 2 replies; 103+ messages in thread From: Nick Roberts @ 1997-05-18 0:00 UTC (permalink / raw) Andrew Dunstan <amd001@its.maynick.com.au> wrote in article <337e56fe.0@news2.maynick.com.au>... > John G. Volan (johnvolan@sprintmail.com) wrote: > : This might be a bit off-topic, but... > [snip] > : ... this has been nagging at me: are "religeon" and "religeous" British > : spellings for "religion" and "religious"? Just curious... :-) > > not according to my SOED :-) But sometimes the religious think themselves righteous. It is interesting to note that many (not all) English, myself included, find it very hard to engage in any kind of argument (i.e. a conversation which involves the slightest disagreement of any kind) without feeling that it implies criticism, and thus being emotional charged. This is the root of the famous taciturn nature of the English: we would often rather simply stay quiet than risk offending somebody. It is not a really a very useful trait. So if some of my arguments appear a bit too 'two-sided', that is, trying to be too appreciative of the counter-argument, now you know why. I am desperately trying not to annoy! I shall retire to the patio now, and sup my Earl Grey tea :-) Nick. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-18 0:00 ` Nick Roberts @ 1997-05-19 0:00 ` John G. Volan 1997-05-19 0:00 ` John G. Volan 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-19 0:00 UTC (permalink / raw) Nick Roberts wrote: > > It is interesting to note that many (not all) English, myself included, > find it very hard to engage in any kind of argument (i.e. a conversation > which involves the slightest disagreement of any kind) without feeling that > it implies criticism, and thus being emotional charged. Hmm, you rather contradict Robert Dewar (another Britisher, I believe), who has on numerous occasions claimed that "an argument" has the positive connotation of "a friendly debate" in England, versus the negative connotation of "a fight" in the United States. > This is the root of > the famous taciturn nature of the English: we would often rather simply > stay quiet than risk offending somebody. It is not a really a very useful > trait. > > So if some of my arguments appear a bit too 'two-sided', that is, trying to > be too appreciative of the counter-argument, now you know why. I am > desperately trying not to annoy! I shall retire to the patio now, and sup > my Earl Grey tea :-) Ah, but here you somewhat concur with Robert, who has also indicated that one is not really qualified to convincingly debate in favor of one's own position, unless one is also prepared to convincingly debate _against_ it. We may debate :-) whether Robert's assertion is justified, but at any rate you put rather a different spin on what might motivate a Britisher to hold such an assertion... :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-18 0:00 ` Nick Roberts 1997-05-19 0:00 ` John G. Volan @ 1997-05-19 0:00 ` John G. Volan 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-19 0:00 UTC (permalink / raw) Nick Roberts wrote: > > Andrew Dunstan <amd001@its.maynick.com.au> wrote in article > <337e56fe.0@news2.maynick.com.au>... > > John G. Volan (johnvolan@sprintmail.com) wrote: > > : This might be a bit off-topic, but... > > [snip] > > : ... this has been nagging at me: are "religeon" and "religeous" British > > : spellings for "religion" and "religious"? Just curious... :-) > > > > not according to my SOED :-) > > But sometimes the religious think themselves righteous. Hmm, there could have been an unconscious association between "religeon" and "dungeon", but so far as I know the last time religious folk spent any significant amount of time hanging around in dungeons was during the office of Torquemada. Rather casts the expression (I paraphrase): "The answer to such people is to either to educate them or to get rid of such people" in a whole new light. :-) Well, I knew I was flirting with heresy... :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` John G. Volan 1997-05-10 0:00 ` Aaron Metzger 1997-05-10 0:00 ` Robert Dewar @ 1997-05-10 0:00 ` Kaz Kylheku 1997-05-10 0:00 ` John G. Volan 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Jeff Carter 4 siblings, 1 reply; 103+ messages in thread From: Kaz Kylheku @ 1997-05-10 0:00 UTC (permalink / raw) In article <3373EAB5.73A0@sprintmail.com>, John G. Volan <johnvolan@sprintmail.com> 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_ Since taking on the learning of Ada95, I have adopted the old Pascal style convention of prefixing 'a' to a capitalized type name: aTree, aList, aStack, etc. In C, I would favor a '_t' suffix, but this appears foreign in Ada source. It just somehow seems impious. Incidentally, the only reason I would use such suffixes is to spare the fundamental type name for use as a variable, e.g. List : aList; Other than that, I'm opposed to elaborate suffix or prefix schemes: that Hungarian Notation thiing is a pet peeve! ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Kaz Kylheku @ 1997-05-10 0:00 ` John G. Volan 0 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-10 0:00 UTC (permalink / raw) Kaz Kylheku wrote: > > Since taking on the learning of Ada95, I have adopted the old Pascal style > convention of prefixing 'a' to a capitalized type name: aTree, aList, > aStack, etc. Except that Ada is case-insensitive, so this should really be "A_Tree", "A_List", "A_Stack". By the way, would it be "An_Airplane" and "An_Item"? Personally, I don't quite like those as names for types. When you do something like this: > List : aList; I think you're trying to cater too much to the "readability AS English" school of thought: "List is a list". I prefer "List_Type" for a list type, because that's what the thing is: a list _type_. Not actually "a list" itself. > Incidentally, the only reason I > would use such suffixes is to spare the fundamental type name for use > as a variable, e.g. Precisely the goal I had in mind, and yes, your scheme would satisfy my criterion that the naming convention be minimalistic and mechanical. I'd just prefer calling a type what it _is_: a "_Type". > Other than that, I'm opposed to elaborate suffix or prefix schemes: > that Hungarian Notation thiing is a pet peeve! I agree that HN is distasteful. It uses cryptic abbreviations -- but that's endemic in C culture anyway. And it obsesses over the detailed machine representation of things -- but that's the fault of the C language itself, what with all the weaknesses in the type system. I mean, when you have implicit coercions, ambiguity between pointers and arays, sentinel values marking the ends of characters strings instead of attribute dope, it's no wonder you'd have to obsess about implementation details. I will give Micro$oft this much credit, however: They seem to apply HN thoroughly and consistently, and _any_ naming convention, if applied consistently, cannot help but enhance readability, once a sufficient number of worker drones^H^H^H^H^H^H ahem, engineers have been indoctrinated^H^H^H^H^H^H^H^H ahem, become familiarized with it. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` John G. Volan ` (2 preceding siblings ...) 1997-05-10 0:00 ` Kaz Kylheku @ 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Jeff Carter 4 siblings, 1 reply; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-12 0:00 UTC (permalink / raw) 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, 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); 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. The above snippet is much clearer as Start_Point, Rotation, End_Point : Angle; ..... End_Point := Start_Point + Rotation; ---------------------------------------------------------------------- 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 s e r v 3 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` W. Wesley Groleau (Wes) @ 1997-05-12 0:00 ` John G. Volan 1997-05-13 0:00 ` W. Wesley Groleau (Wes) 0 siblings, 1 reply; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) 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, why should I be forced to call that object anything other than the simple word "Angle"? > 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.) 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; ... End_Angle := Start_Angle + Rotation_Angle; or perhaps: procedure Rotate (Angle : in out Angle_Type; Rotation_Angle : in Angle_Type) is begin Angle := Angle + Rotation_Angle; end Rotate; My scheme has the advantage that a "specific" identifier such as "Start_Angle" is clearly the name of an object, and can never be confused as the name of a "specific" derived- or sub-type of Angle_Type. A subtype or derived type would always be marked "_Type" just like any other type: type Angle_Type is digits ... ; -- for angular values in general (in degrees) subtype Proper_Angle_Type is Angle_Type range 0.0 .. Angle_Type'Pred(360.0); -- for angular values constrained to non-negatives -- within one cycle subtype Signed_Angle_Type is Angle_Type range -180.0 .. Angle_Type'Pred(+180.0); type Direction_Type is new Proper_Angle_Type; -- for navigational compass-directions type Longitude_Type is new Signed_Angle_Type; -- for geographic longitudes > 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): type Angle_Real is digits ...; -- "Real" marks it as a floating point type Angle : Angle_Real; I say, why encode such an implementation detail into the type name and not inro the object name, too? You should either encode it in both or in neither (and I strongly favor encoding it in neither!) > The above snippet is much clearer as > > 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; ... End_Angle := Start_Angle + Rotation_Angle; ... function Get_Rotation (Angle : in Angle_Type) return Rotation_Type; -- generates coordinate transformation matrix to rotate -- points around the origin by the given angle function "*" (Rotation : in Rotation_Type; Point : in Point_Type) return Point_Type; -- applies rotational transformation matrix to point ... Start_Point, End_Point : Point_Type; Rotation : constant Rotation_Type := Get_Rotation (Angle => Rotation_Angle); ... End_Point := Rotation * Start_Point; ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` John G. Volan @ 1997-05-13 0:00 ` W. Wesley Groleau (Wes) 1997-05-13 0:00 ` John G. Volan 0 siblings, 1 reply; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-13 0:00 UTC (permalink / raw) 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` W. Wesley Groleau (Wes) @ 1997-05-13 0:00 ` John G. Volan 1997-05-14 0:00 ` Do-While Jones 1997-05-14 0:00 ` naming convention discussion Peter Hermann 0 siblings, 2 replies; 103+ messages in thread From: John G. Volan @ 1997-05-13 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-13 0:00 ` John G. Volan @ 1997-05-14 0:00 ` Do-While Jones 1997-05-14 0:00 ` John G. Volan 1997-05-14 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Stephen Leake 1997-05-14 0:00 ` naming convention discussion Peter Hermann 1 sibling, 2 replies; 103+ messages in thread From: Do-While Jones @ 1997-05-14 0:00 UTC (permalink / raw) Speaking from a maintenance point-of-view, I certainly prefer package Angles is type Degrees is digits ...; to > package Angles is > > type Angle_Type is digits ...; -- in degrees because it eliminates the need to "grep Angle_Type angles.ads" to see if a variable of Angle_Type (declared in a different package) is expressed in degrees or radians. Never express in a comment that which can be expressed in the code. DIRECTION : Angles.Degrees; is safer than DIRECTION : Angles.Angle_Type; -- in degrees Furthermore, one is more likely to make this mistake: THETA_IN_RADIANS : Angles.Angle_Type; than to make this mistake: THETA_IN_RADIANS : Angles.Degrees; Do-While Jones -- Science Against Evolution is a California Public Benefit Corporation whose objective is to make the general public aware that the theory of evolution is not consistent with physical evidence and is no longer a respectable theory describing the origin of life. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-14 0:00 ` Do-While Jones @ 1997-05-14 0:00 ` John G. Volan 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Tangent to Religious naming convention discussion W. Wesley Groleau (Wes) 1997-05-14 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Stephen Leake 1 sibling, 2 replies; 103+ messages in thread From: John G. Volan @ 1997-05-14 0:00 UTC (permalink / raw) Do-While Jones wrote: > > Speaking from a maintenance point-of-view, I certainly prefer > > package Angles is > > type Degrees is digits ...; Do-While, you're running the risk here of resurrecting another unkillable thread... :-) My emphasis has been that if you have a clear abstraction (=concept=object class) then naming should just fall out of that. People have been side-tracking this point by moving the abstraction boundaries around. If I answer this, I run the risk of yet another tangent. Oh, well, here goes anyway: What if the units are an implementation detail that you want to hide? What if you decide later that, for efficiency reasons, all Angles are best implemented in radians rather than degrees? Then your suggestion would lie closer to the Hungarian end of the naming spectrum: encoding implementation details in the name. with Unitless; package Angles is type Angle_Type is private; -- Going with a private type is a tough decision here. -- I'm not necessarily recommending it. An alternative -- could be to make this a visible float type and just -- override as abstract any built-in functions (e.g. "*") -- that violate unit dimensionality. But as an academic -- exercise, let's see where this leads us ... function "*" (Left : Unitless.Quantity_Type; Right : Angle_Type) return Angle_Type; function "*" (Left : Angle_Type; Right : Unitless.Quantity_Type) return Angle_Type; function "/" (Left : Angle_Type; Right : Angle_Type) return Unitless.Quantity_Type; ... -- etc. -- the following are functions rather than constants -- in order to make them inheritable function Zero return Angle_Type; function Degree return Angle_Type; function Radian return Angle_Type; function Cycle return Angle_Type; -- = 360.0*Degree = 2.0*Pi*Radian function Hemicycle return Angle_Type; -- = 180.0*Degree = Pi*Radian function Quadrant return Angle_Type; -- = 90.0*Degree = 0.5*Pi*Radian ... etc. function Get_Complement -- = Quadrant - Angle (Angle : in Angle_Type) return Angle_Type; function Get_Supplement -- = Hemicycle - 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; ... -- etc. end Angles; > Never express in a comment that which can be expressed in the code. > > DIRECTION : Angles.Degrees; > > is safer than > > DIRECTION : Angles.Angle_Type; -- in degrees Or perhaps: with Angles; package Directions is type Direction_Type is new Angles.Proper_Angle_Type; function North return Direction_Type renames Zero; function Northeast return Direction_Type; -- = 45.0*Degree = 0.5*Quadrant function East return Direction_Type renames Quadrant; -- = 90.0*Degree function Southeast return Direction_Type; -- = 135.0*Degree = 1.5*Quadrant function South return Direction_Type renames Hemicycle; -- = 180.0*Degree = 2.0*Quadrant ... -- etc. end Directions; And then somewhere: Direction : Directions.Direction_Type; -- I don't care what the units are, -- the abstraction protects me from them > Furthermore, one is more likely to make this mistake: > > THETA_IN_RADIANS : Angles.Angle_Type; > > than to make this mistake: > > THETA_IN_RADIANS : Angles.Degrees; > Or perhaps: Theta_Angle : Angles.Angle_Type; -- I don't care what the units are, -- the abstraction protects me from them ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-14 0:00 ` John G. Volan @ 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Tangent to Religious naming convention discussion W. Wesley Groleau (Wes) 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-14 0:00 UTC (permalink / raw) John G. Volan wrote: > > function Get_Proper_Form -- a kind of "abs" for angles > (Angle : in Angle_Type) > return Proper_Angle_Type; ^^^^^^^^^^^^^^^^^ Woops, I forgot that if I make Angle_Type private I lose the ability to have visible constrained subtypes. Should be: function Get_Proper_Form (Angle : in Angle_Type) return Angle_Type; function Is_Proper_Form -- substitutes for (Angle : in Angle_Type) -- subtype membership test return Boolean; > with Angles; > package Directions is > > type Direction_Type is new Angles.Proper_Angle_Type; > Should be: type Direction_Type is new Angles.Angle_Type; function Is_Valid -- i.e., as a Direction (Direction : in Direction_Type) return Boolean renames Is_Proper_Form; function Get_Valid_Form -- i.e., for a Direction (Direction : in Direction_Type) return Direction_Type renames Get_Proper_Form; ... ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Tangent to Religious naming convention discussion ...... 1997-05-14 0:00 ` John G. Volan 1997-05-14 0:00 ` John G. Volan @ 1997-05-15 0:00 ` W. Wesley Groleau (Wes) 1997-05-15 0:00 ` John G. Volan 1 sibling, 1 reply; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-15 0:00 UTC (permalink / raw) John G. Volan wrote: > with Unitless; > package Angles is > > type Angle_Type is private; This is an excellent approach (though in itself it doesn't support the "_Type" concept--to lessen :-) the "tangent"). Just make sure you provide the clients with something like function Degrees ( From : Angle[_Type] ) return Float; -- or at least function Degrees_Image ( From : Angle[_Type] ) return String; > -- Going with a private type is a tough decision here. There is a disadvantage (easily overcome) to losing the use of attributes, .... > -- I'm not necessarily recommending it. An alternative > -- could be to make this a visible float type and just ^^^^^^^^^^^^^^^^^^ > -- override as abstract any built-in functions (e.g. "*") > -- that violate unit dimensionality. .... but this way some fool is sure to peek into your package body and, taking advantage of the "fact" that you implemented in Radians, write something like: Put_Line ( "Heading:" & Integer'Image ( Integer ( Heading * 180.0 / Pi ) ) ); Before we go off on _another_ tangent about engineering discipline, remember that many software "engineers" develop a strange form of insanity when managers start grumbling about schedules..... ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Tangent to Religious naming convention discussion ...... 1997-05-15 0:00 ` Tangent to Religious naming convention discussion W. Wesley Groleau (Wes) @ 1997-05-15 0:00 ` John G. Volan 0 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-15 0:00 UTC (permalink / raw) W. Wesley Groleau (Wes) wrote: > > John G. Volan wrote: > > with Unitless; > > package Angles is > > > > type Angle_Type is private; > > This is an excellent approach (though in itself it doesn't > support the "_Type" concept--to lessen :-) the "tangent"). > Just make sure you provide the clients with something like > > function Degrees ( From : Angle[_Type] ) return Float; > -- or at least > function Degrees_Image ( From : Angle[_Type] ) return String; Float may not be very appropriate if Angle_Type isn't implemented with Float. I was assuming that Unitless.Quantity_Type was a floating-point type with some connection to Angle_Type's implementation. Technically speaking, the functionality you suggest is already provided by "/": Degrees_Quantity : Unitless.Quantity_Type := Some_Angle / Degree; -- angle / angle = unitless -- Since we're reducing this to a unitless coefficient with -- the "angle" dimension stripped off, we now have to keep -- track of what units we used to reduce it, hence the -- encoding of "Degrees" in the name. The reverse operation is "*": Some_Angle : Angle_Type := Degrees_Quantity * Degree; -- unitless * angle = angle For efficiency reasons, however, I can see the rationale for avoiding division as the method for doing the reduction (especially if the internal units happen to be degrees), but if you're going to include functions like the one you suggested, they should be written in terms of Unitless.Quantity_Type: function In_Degrees (Angle : Angle_Type) return Unitless.Quantity_Type; -- ^^^^^^^^^^^^^^^^^^^^^^ Degrees_Quantity : Unitless.Quantity_Type := In_Degrees (Angle => Some_Angle); In other words, the Angles package is part of an integrated subsystem of dimensional units packages, with Unitless providing a floating-point "unitless" Quantity_Type which acts as the common numeric currency for the subsystem. "Unitful" private types such as Angle_Type presumably use Quantity_Type as their underlying representation, either by being privately derived from it or perhaps being records with one Quantity_Type component. Unitless.Quantity_Type might very well be (an unconstrained subtype of) Float'Base, or derived from Float'Base, or it might be some user-defined float, or it might be (hint-hint) derived from some generic formal floating point type parameter defining the floating-point representation for the subsystem. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-14 0:00 ` Do-While Jones 1997-05-14 0:00 ` John G. Volan @ 1997-05-14 0:00 ` Stephen Leake 1 sibling, 0 replies; 103+ messages in thread From: Stephen Leake @ 1997-05-14 0:00 UTC (permalink / raw) Do-While Jones wrote: > > Speaking from a maintenance point-of-view, I certainly prefer > > package Angles is > > type Degrees is digits ...; > > to > > > package Angles is > > > > type Angle_Type is digits ...; -- in degrees > > because it eliminates the need to "grep Angle_Type angles.ads" to see if a > variable of Angle_Type (declared in a different package) is expressed in > degrees or radians. But this package does not prevent someone from writing: Angle_In_Radians : Angles.Degrees := Item / 360.0; If you are trying to enforce units, you need a private type. But then you need a system of private types providing all units, so this is not an isolated case. > > Never express in a comment that which can be expressed in the code. > More importantly, don't pretend you are providing an abstraction that you are not! > > Do-While Jones > -- - Stephe ^ permalink raw reply [flat|nested] 103+ messages in thread
* naming convention discussion 1997-05-13 0:00 ` John G. Volan 1997-05-14 0:00 ` Do-While Jones @ 1997-05-14 0:00 ` Peter Hermann 1997-05-14 0:00 ` John G. Volan 1 sibling, 1 reply; 103+ messages in thread From: Peter Hermann @ 1997-05-14 0:00 UTC (permalink / raw) John G. Volan (johnvolan@sprintmail.com) wrote: : package Angles is [etc] this contribution was quite interesting to me. I am just in (infinite) search for the best method for myself. One thing which I observed on myself was the positive fact, that when I forced myself to omit the "_type"-extension, I was indeed forced to think deeper about the correct meaning of both objects and types of the abstraction; which in turn led to better names. You may try it yourself ;-) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention discussion 1997-05-14 0:00 ` naming convention discussion Peter Hermann @ 1997-05-14 0:00 ` John G. Volan 1997-05-14 0:00 ` Peter Hermann 0 siblings, 1 reply; 103+ messages in thread From: John G. Volan @ 1997-05-14 0:00 UTC (permalink / raw) Peter Hermann wrote: > > One thing which I observed on myself was the positive fact, > that when I forced myself to omit the "_type"-extension, > I was indeed forced to think deeper IMHO, thinking deeply about the kind of name distinctions I've been talking about is wasted effort. > about the correct meaning of > both objects and types of the abstraction; I do that anyway. What you describe is the tail wagging the dog: Use the great name hunt as the way to force you to analyze your semantics. I say, think deep thoughts about the semantics (e.g., do some object-oriented analysis, build OMT or UML models, etc.), and then let the names fall out automatically from that. > which in turn led to better names. > You may try it yourself ;-) Oh, I have, I have. Gave it up as a lost cause... :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention discussion 1997-05-14 0:00 ` John G. Volan @ 1997-05-14 0:00 ` Peter Hermann 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` W. Wesley Groleau (Wes) 0 siblings, 2 replies; 103+ messages in thread From: Peter Hermann @ 1997-05-14 0:00 UTC (permalink / raw) John G. Volan (johnvolan@sprintmail.com) wrote: : Oh, I have, I have. Gave it up as a lost cause... :-) Although this is certainly the ultimate wisdom for all of us, I can't stop trying to improve my habits. Not to strive for this would mean I am old ;-) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention discussion 1997-05-14 0:00 ` Peter Hermann @ 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Peter Hermann 1997-05-15 0:00 ` W. Wesley Groleau (Wes) 1 sibling, 1 reply; 103+ messages in thread From: John G. Volan @ 1997-05-14 0:00 UTC (permalink / raw) Peter Hermann wrote: > > John G. Volan (johnvolan@sprintmail.com) wrote: > : Oh, I have, I have. Gave it up as a lost cause... :-) > > Although this is certainly the ultimate wisdom for all of us, > I can't stop trying to improve my habits. > Not to strive for this would mean I am old ;-) > > -- > Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de > Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen > Team Ada: "C'mon people let the world begin" (Paul McCartney) Clarification: I meant that I gave up on good names => good semantics in favor of good semantics => good names ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention discussion 1997-05-14 0:00 ` John G. Volan @ 1997-05-15 0:00 ` Peter Hermann 0 siblings, 0 replies; 103+ messages in thread From: Peter Hermann @ 1997-05-15 0:00 UTC (permalink / raw) John G. Volan (johnvolan@sprintmail.com) wrote: : good names => good semantics : in favor of : good semantics => good names good semantics <=> good names :-) :-) :-) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: naming convention discussion 1997-05-14 0:00 ` Peter Hermann 1997-05-14 0:00 ` John G. Volan @ 1997-05-15 0:00 ` W. Wesley Groleau (Wes) 1 sibling, 0 replies; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-15 0:00 UTC (permalink / raw) > I can't stop trying to improve my habits. > Not to strive for this would mean I am old ;-) Thanks--I was looking for an excuse to stop trying :-) ---------------------------------------------------------------------- Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA Not Yet Fifty But On The Way 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` John G. Volan ` (3 preceding siblings ...) 1997-05-12 0:00 ` W. Wesley Groleau (Wes) @ 1997-05-12 0:00 ` Jeff Carter 1997-05-12 0:00 ` John G. Volan 4 siblings, 1 reply; 103+ messages in thread From: Jeff Carter @ 1997-05-12 0:00 UTC (permalink / raw) John G. Volan wrote: ... > (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 AQ&S is generally too vague and contradictory to be useful. This is perhaps best demonstrated by the fact that its "complete example" does not conform to its recommended style, and contains errors. ... > type Error_Count_Type is range 0 .. Error_Limit; > ... > Error_Count : Error_Count_Type; -- counts errors flagged so far type Error_Count is range ... Num_Errors : Error_Count; > > versus > > type Error_Ident_Type is range Minimum_Error_Ident .. > Maximum_Error_Ident; > ... > Error_Ident : Error_Ident_Type; -- identifies the last error flagged type Error_Id is ... Last_Error : Error_Id; > > But, as you can see, you're still faced with the problem of generating a > different identifier for the type. Nope. See above. > > 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. You should never tack type suffixes onto object names. That's adding type information to object identifiers. That should be unnecessary. That's what M$'s horrible Hungarian notation is. Although I claimed in jest to be religious about this, I trust that the jest was obvious. I'm most interested in creating readable code; I don't always stick these suffixes on type names. Note, for example, the type Position in the List example. -- Jeff Carter PGP:1024/440FBE21 Auntie-spam reply to; try ( carter @ innocon . com ) "Now go away, or I shall taunt you a second time." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Jeff Carter @ 1997-05-12 0:00 ` John G. Volan 0 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) Jeff Carter wrote: > > type Error_Count is range ... > Num_Errors : Error_Count; Nope, that's the synonym method, semantically uneconomical. type Num_Errors_Type is range ...; Num_Errors : Num_Errors_Type; But I don't want to use plurals in type/object names, because I want to reserve the plural form as my marker for a package. > type Error_Id is ... > Last_Error : Error_Id; Nope, that's marking the object with a "specific" adjective. If "error" is enough to convey the sense that it's an id and not a count, then why not just dispense with "_id"? Last_Error : Error; -- marking the object vs. the type But what would you do if you're in a context where you don't have any convenient adjective for the situation? Resort to a default marker? ("The_"?) I say, mark the type and don't force programmers to mark the objects. e.g., My scheme: procedure Display (Error : in Error_Type); -- it' just some error you want displayed -- not necessarily the last one Your scheme (?): procedure Display (The_Error : in Error); -- marking the object vs. the type ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jeff Carter 1997-05-09 0:00 ` John G. Volan @ 1997-05-09 0:00 ` John G. Volan 1997-05-10 0:00 ` Robert Dewar ` (3 subsequent siblings) 5 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-09 0:00 UTC (permalink / raw) Jeff Carter wrote: > According to my religion, you guys are heretics. I will give the command > to my followers that you should be killed on sight. Now, if I only had > some followers ... ... > Continue in your heresy, and we will burn you alive. Convert, and we > will merely behead you. By the way, ya oughtta _smile_ when ya say that, pardner. Or at least, smiley... :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jeff Carter 1997-05-09 0:00 ` John G. Volan 1997-05-09 0:00 ` John G. Volan @ 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` John G. Volan 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-11 0:00 ` Doug Smith ` (2 subsequent siblings) 5 siblings, 2 replies; 103+ messages in thread From: Robert Dewar @ 1997-05-10 0:00 UTC (permalink / raw) John Volan says <<"John G. Volan" <johnvolan@sprintmail.com> writes: ... >I only wish the original designers of Ada83 had clued into this style >from the start. I find myself wishing Ada95 looked more like this: > Integer : Integer_Type; > Natural : Natural_Type; > Float : Float_Type; > Boolean : Boolean_Type; > Character : Character_Type; > String : String_Type; > Duration : Duration_Type;>> It really is remkarable how some people can take a good idea, and then kill it by applying it in a completely blind manner. Assuming (a bit of a reach) that the above is NOT meant as humour, I really find it hard to believe that anyone would prefer Integer_Type to Integer. For the last 40 years, millions of programmers have read billions or even trillions of lines of code in which we have a firm convention of using very simple words like int or Integer for simple predefined types. Why would anyone want to type extra junk in their program to override this universal convention? At the same time, I find it quite reasonable to add a suffix of _Type in cases which are less familiar and where it helps the reader. For my view of the dividing line look at the GNAT sources. So for example, universal integers, which are so pervasive, are called Uint, but on the other hand, we use Line_Number_Type. I do not see for a moment that changing Uint to Universal_Integer_Type throughout the GNAT sources would achieve anything except to make the sources a bit harder to read, and to increase the size of the tar file! In its blind use-it-all-the-time mode suggested above, I find the _Type suffix rule to be similar to the horrible encoding rules that some C coders use. P.S. The issue of how much to worry about classification of names like this quite depends on availabilty of tools. If you have a tool (like GNAT running under EMACS using GNATF to provide xref information) that allows you to instantantly locate the defining occurrence of a given identifier (useful Algol-68 term :-) then the balance shifts in favor of less encoding. The trouble is that in choosing a name, we are trying to satisfy two needs at the same time. o Give maximum help to someone looking at the sources for the first time who does not know their way around. o Don't generate too much unnecessary noise for someone who *does* know their way around the sources. Obviously familiarity plays a big role. Every Ada programmer knows the type name Integer, and therefore changing it to Integer_Type would badly damage the second objective without helping the first objective. On the other hand, a less familiar type name may suggest giving more weight to the first objective. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Robert Dewar @ 1997-05-10 0:00 ` John G. Volan 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1 sibling, 2 replies; 103+ messages in thread From: John G. Volan @ 1997-05-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > > John Volan says > > <<"John G. Volan" <johnvolan@sprintmail.com> writes: > ... > >I only wish the original designers of Ada83 had clued into this style > >from the start. I find myself wishing Ada95 looked more like this: > > > Integer : Integer_Type; [snip] > It really is remkarable how some people can take a good idea, and then > kill it by applying it in a completely blind manner. Assuming (a bit > of a reach) that the above is NOT meant as humour, I really find it > hard to believe that anyone would prefer Integer_Type to Integer. > For the last 40 years, millions of programmers have read billions or > even trillions of lines of code in which we have a firm convention of > using very simple words like int or Integer for simple predefined types. > Why would anyone want to type extra junk in their program to override > this universal convention? Obviously I was writing science fiction in trying to describe a parallel universe where the original Ada83 designers ignored the prevailing convention of: X : INTEGER; i.e., totally cryptic short variable name inspired by the cryptic notation of mathematics (because the first applications of computers happened to be purely mathematical), and required to be different from the nicely readable simple unmarked type name, because the type name got the simple unmarked word first. Well, in this universe, they didn't ignore convention, so we got what we got, and I can live with that. The trouble, though, is that the way the standard types are dealt with, and the style in which the standard packages are written, has had an influence on programmers, such that it's sometimes hard for them to see (at first) the utility of adopting a style like the one I described, meeting the kind of criteria that I described. So you wind up with abominations like: T : Target; The usual argument is: "Hey, c'mon, it's not so bad, you and I both know that T is a target. It's just like what they did in the RM, so it must be cool. Look at the standard packages, man. How come they just use "E" for an exception identity? Don't be so uptight, dude..." And then about 100 lines later the reader is lost in a morass of statements referencing a dozen or so one- or two-character variable names, and has no clue what is going on. > At the same time, I find it quite reasonable to add a suffix of _Type > in cases which are less familiar and where it helps the reader. For > my view of the dividing line look at the GNAT sources. So for example, > universal integers, which are so pervasive, are called Uint, but > on the other hand, we use Line_Number_Type. I do not see for a moment > that changing Uint to Universal_Integer_Type throughout the GNAT sources > would achieve anything except to make the sources a bit harder to read, > and to increase the size of the tar file! I do not object at all to a project choosing a set of abbreviations as an internal convention, as long as they document them and are consistent. But what is consistency? Remember my notion of "semantic economy". I would have said, if "Uint" makes a good label for the concept of "universal integer", why resort to another, less informative label (perhaps "U" for a variable name) for the same concept? Why not use that label in every context refering to "universal integers", including both the type name and a representative object name: Uint : Uint_Type; Now would that _really_ have made the tar file all that much bigger? And is the tar file size really such an overriding concern? If so, then why bother with such a long name as "Line_Number_Type"? Why not just "Line_Type" or even "LN_Type" (of course, with documentation somewhere stating that "LN" is your project abbreviation for "Line_Number"). That way, instead of having: Line_Number : Line_Number_Type; -- good, but maybe too verbose or L : Line_Number_Type; -- bad, information loss, semantically uneconomical you could have: Line : Line_Type; --good or even: LN : LN_Type; -- okay, but only with prominent documentation Although I have tried to show how some aspects of the name selection process can be rendered mechanical, nevertheless there is still room for it to be something of an art form. > In its blind use-it-all-the-time mode suggested above, I find the _Type > suffix rule to be similar to the horrible encoding rules that some C > coders use. I'm surprised you didn't raise the old canard, "A foolish consistency is the hobgoblin of small minds." (This is sometimes misunderstood to mean that all consistency is foolish, or that any uncompromising consistency is foolish. This is clearly not true: My heart has been beating consistently for almost 36 years, and I am quite glad it has not chosen to compromise on that at _any_ point! :-) But really, taking the scheme I described and comparing it to certain C conventions (I assume you must be referring to Hungarian Notation) is quite unfair. You might have noticed that I have been arguing in favor of _minimal_ encoding -- just what is needed to distinguish identifiers to make the compiler happy, without forcing the programmer to think up multiple words (or resort to _arbitrary_ abbreviations) for the same concept (in short, "semantic economy.") I certainly don't subscribe to the notion that a type or object name must encode _all_ implementation details, like what size integer it is or whether its signed or unsigned, and so forth. (Certainly not given Ada's type model.) > P.S. The issue of how much to worry about classification of names like > this quite depends on availabilty of tools. If you have a tool (like > GNAT running under EMACS using GNATF to provide xref information) that > allows you to instantantly locate the defining occurrence of a given > identifier (useful Algol-68 term :-) then the balance shifts in favor > of less encoding. > > The trouble is that in choosing a name, we are trying to satisfy two needs > at the same time. > > o Give maximum help to someone looking at the sources for the first > time who does not know their way around. > > o Don't generate too much unnecessary noise for someone who *does* know > their way around the sources. > > Obviously familiarity plays a big role. Every Ada programmer knows the > type name Integer, and therefore changing it to Integer_Type would badly > damage the second objective without helping the first objective. Of course I was not seriously suggesting changing something like "Integer", not at this stage. The only way to change such a massive convention would be to go back and change history itself, but unfortunately the last time the Enterprise bounced back to the 20th century, they neglected to leave behind any temporal-anomaly generators. :-) > On the other hand, a less familiar type name may suggest giving more weight > to the first objective. Hmm. "Familiarity" is such a subjective criterion, kind of hard to pin it down as a simple set of rules for a naming convention. One man's second nature can be another man's alien jargon. De gustabus non disputandum est. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` John G. Volan @ 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1 sibling, 1 reply; 103+ messages in thread From: Robert Dewar @ 1997-05-11 0:00 UTC (permalink / raw) 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; 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; I have *never* wanted to call a variable Integer, and that is why in this case Integer is the right name for the type. 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-11 0:00 ` Robert Dewar @ 1997-05-12 0:00 ` John G. Volan 0 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` John G. Volan 1997-05-11 0:00 ` Robert Dewar @ 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1 sibling, 0 replies; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-12 0:00 UTC (permalink / raw) > .... So you wind up with abominations like: > > T : Target; > > The usual argument is: "Hey, c'mon, it's not so bad, you and I both > know that T is a target. It's just like what they did in the RM, so > it must be cool. Look at the standard packages, man. How come they > just use "E" for an exception identity? ...." This (and a recent post about AQ&S not following its own guidelines) illustrates a principle of documentation: People follow examples, not guidelines. In other words, "Do as I say, not as I do" almost never works! ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` John G. Volan @ 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` John G. Volan 1 sibling, 1 reply; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > The trouble is that in choosing a name, we are trying to satisfy two > needs at the same time. > > o Give maximum help to someone looking at the sources for the > first time who does not know their way around. > > o Don't generate too much unnecessary noise for someone who *does* > know their way around the sources. The trouble with "letting rules substitute for judgment" is that you end up generating unnecessary noise for _both_ groups but not giving much help to either! ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` W. Wesley Groleau (Wes) @ 1997-05-12 0:00 ` John G. Volan 0 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > The trouble is that in choosing a name, we are trying to satisfy two > needs at the same time. > > o Give maximum help to someone looking at the sources for the > first time who does not know their way around. > > o Don't generate too much unnecessary noise for someone who *does* > know their way around the sources. There is also: o Give the original author a semantic framework that he can hang his concepts on, clear the cobwebs out of his own thinking, and actually write the code he intends to write without losing track of what he's doing with what... W. Wesley Groleau (Wes) wrote: > > The trouble with "letting rules substitute for judgment" is that you > end up generating unnecessary noise for _both_ groups but not giving > much help to either! This is misguided. There should be no need to waste energy on "judgment" regarding aspects of software development that ought to be _purely mechanical_. For example, once a software designer has identified the concepts (object classes) that make up an application, generating names for the program elements that implement those concepts should be automatic, and not require any "judgement." The engineer's "judging" faculties are better spent on more important issues, such as actually implementing the data structures and algorithms that are to be affixed to these names. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jeff Carter ` (2 preceding siblings ...) 1997-05-10 0:00 ` Robert Dewar @ 1997-05-11 0:00 ` Doug Smith 1997-05-12 0:00 ` Tom Moran 1997-05-16 0:00 ` Wayne Magor 5 siblings, 0 replies; 103+ messages in thread From: Doug Smith @ 1997-05-11 0:00 UTC (permalink / raw) In article <3373666A.31DFF4F5@spam.innocon.com>, Jeff Carter <carter@spam.innocon.com> wrote: [snip] > 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 use > many; here are a few: > > Numeric types: _Value, _Count, _Range > Enumeration types: _Id, _Name > Array types: _Set, _List > Record types: _Group, _Data, _Info > Task types: _Agent, _Controller > Private types: _Handle > > I'm also creative in my use of parameter names, using Into, Before, > After, From, To, and so on to avoid as much of this as I can: > > procedure Insert (Into : in out String; Before : in Positive; Value : in > String); > procedure Append (Onto : in out List_Handle; After : in Position; Item : > in Element); [snip] > -- > Jeff Carter PGP:1024/440FBE21 Several years ago, I found an excellent article on user interface design in Smithsonian magazine (no that is not a typo!) Two of the three principles were: 1) Make usage obvious, and 2) Use conventions. Other posters have applied these principles, but I like Jeff's usage of the suffix much better. Let me go a little further. We have not addressed the semantics issue very well. I think Jeff's reference to private type handles alludes to object semantics. If a naming convention grows out of certain common semantics, then usage will be more obvious. For example, I might expect certain operations and associated semantics with any type which has the _Set suffix. By convention, I would expect the union and intersection operations and the the default value of Null, etc. This naming convention may apply also to package names, as Booch used in his reusable components (although I found the architecture cumbersome). Then, as Jeff suggests, the suffix can distinguish between types, especially related types used in the same package such as _Info and _Handle. In fact, I have seen and used the suffix alone: Object, Class, or Handle. It is unlikely we will agree on any community-wide convention, but at least each reusable library should have some "foolish" consistency. Now to argue the other side, when there are no conventions which describe a type's semantics, then don't use a suffix: use a descriptive, general name. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jeff Carter ` (3 preceding siblings ...) 1997-05-11 0:00 ` Doug Smith @ 1997-05-12 0:00 ` Tom Moran 1997-05-16 0:00 ` Wayne Magor 5 siblings, 0 replies; 103+ messages in thread From: Tom Moran @ 1997-05-12 0:00 UTC (permalink / raw) > So why not use > the shortest possible suffix, 2 characters: _T? The plural, commonly just the letter "S", is even shorter. Doodad, Gewgaw, Thingamajig : Widgets; ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Jeff Carter ` (4 preceding siblings ...) 1997-05-12 0:00 ` Tom Moran @ 1997-05-16 0:00 ` Wayne Magor 1997-05-16 0:00 ` John G. Volan 1997-05-17 0:00 ` Kevin Cline 5 siblings, 2 replies; 103+ messages in thread From: Wayne Magor @ 1997-05-16 0:00 UTC (permalink / raw) Jeff Carter <carter@spam.innocon.com> writes: >Jay Martin wrote: >> >> "John G. Volan" <johnvolan@sprintmail.com> writes: >> ... >> >I only wish the original designers of Ada83 had clued into this style >> >from the start. I find myself wishing Ada95 looked more like this: >> >> > Integer : Integer_Type; >> > Natural : Natural_Type; >> > Float : Float_Type; >> > Boolean : Boolean_Type; >> > Character : Character_Type; >> > String : String_Type; >> > Duration : Duration_Type; > >But it wastes fewer characters than the equally ugly _Type. Using _Type *is* ugly, but we use it fairly often anyway. Requiring it in coding standards is a very bad idea. Sure, it is mechanical, but it does not allow the very natural Units package we typically use. Example: Altitude : Units.Feet; Latitude : Units.Radians; Rate : Units.Hertz; It's pretty important to know that Altitude is in feet and not nautical miles or meters. It's also pretty important to know what is in Degrees and what is in Radians. This is the most straightforward and elegant solution, IMHO. >Numeric types: _Value, _Count, _Range >Enumeration types: _Id, _Name >Array types: _Set, _List >Record types: _Group, _Data, _Info >Task types: _Agent, _Controller >Private types: _Handle These are fairly natural, I can find many examples of those exact uses in our software, however, as I stated above, requiring type names with those suffixes is not wise. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-16 0:00 ` Wayne Magor @ 1997-05-16 0:00 ` John G. Volan 1997-05-17 0:00 ` Kevin Cline 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-16 0:00 UTC (permalink / raw) Wayne Magor wrote: > > Altitude : Units.Feet; > Latitude : Units.Radians; > Rate : Units.Hertz; > > It's pretty important to know that Altitude is in feet and not nautical miles > or meters. It's also pretty important to know what is in Degrees and what > is in Radians. This is the most straightforward and elegant solution, IMHO. I'll say it again: If something is important enough to say in the type, then it's just as important to say it in the object names, too: Altitude_Feet : Units.Feet; Altitude_Meters : Units.Meters; Latitude_Radians : Units.Radians; Latitude_Degrees : Units.Degrees; Rate_Hertz : Units.Hertz; Rate_Megahertz : Units.Megahertz; If you're using many different units for the same kinds of quantity, all in the same program, then it's important to keep them all straight. But this pattern is basically just Booch style: <specific_modifier>_<general_noun> : <general_noun>; (For example "Altitude" can be seen as the specific modifier attached to the general noun "Feet".) Now, if you can guarantee me that you'll always be attaching some modifier or other, then this approach is workable. (Just don't ask me to try this sort of thing on my object-oriented abstractions... "The_" is just noise.) On the other hand, if your project intends to settle on _one_ standard universal unit for each type of quantity (a good idea anyway), then embedding the unit name in the objects, or the types, or both, is just noise (i.e., Hungarianism). Better to just say, a la Booch: The_Altitude : Altitude; The_Latitude : Latitude; The_Rate : Rate; or, a la Cohen: Altitude : Altitude_Type; Latitude : Latitude_Type; Rate : Rate_Type; Sure, it'll take discipline to always keep to the project-standard units. But (short of wrapping these up as private types) keeping to the units would take discipline _anyway_. Just because the type name says "Feet" doesn't guarantee programmers will always remember to treat them as feet... but if you think the programmers need reminding, better remind them with every object! ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-16 0:00 ` Wayne Magor 1997-05-16 0:00 ` John G. Volan @ 1997-05-17 0:00 ` Kevin Cline 1997-05-19 0:00 ` Doug Smith 1 sibling, 1 reply; 103+ messages in thread From: Kevin Cline @ 1997-05-17 0:00 UTC (permalink / raw) wemagor@sym1.cca.rockwell.com (Wayne Magor) wrote: >It's pretty important to know that Altitude is in feet and not nautical miles >or meters. It's also pretty important to know what is in Degrees and what >is in Radians. This is the most straightforward and elegant solution, IMHO. It's not important if direct conversion to or from a numeric type is impossible. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-17 0:00 ` Kevin Cline @ 1997-05-19 0:00 ` Doug Smith 0 siblings, 0 replies; 103+ messages in thread From: Doug Smith @ 1997-05-19 0:00 UTC (permalink / raw) In article <6650FD690224F234.CA8B0C59DCFC9927.43A53422559505C5@library-proxy.airnews.net>, clines@delete_this.airmail.net (Kevin Cline) wrote: > wemagor@sym1.cca.rockwell.com (Wayne Magor) wrote: > > >It's pretty important to know that Altitude is in feet and not nautical miles > >or meters. It's also pretty important to know what is in Degrees and what > >is in Radians. This is the most straightforward and elegant solution, IMHO. > > It's not important if direct conversion to or from a numeric type is > impossible. I am not set on one approach or another. However, I do prefer something like: with Linear_Measurement; ... type Altitude is private; function Feet (Value : in Linear_Measurement.Feet) return Altitude; function Miles (Value : in Linear_Measurement.Miles) return Altitude; ... function Feet (Value : in Altitude) return Linear_Measurement.Feet; function Miles (Value : in Altitude) return Linear_Measurement.Miles; ... This suggests an architecture, but a fully detailed solution would include some package hierarchy and/or abstract type for handling units without the need to declare all conversions for all dimensions. Doug <mailto:dsmith@clark.net> ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-08 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan 1997-05-09 0:00 ` Jay Martin @ 1997-05-09 0:00 ` Kevin Cline 1997-05-09 0:00 ` John G. Volan 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 2 siblings, 1 reply; 103+ messages in thread From: Kevin Cline @ 1997-05-09 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> wrote: >Charles H. Sampson wrote: > >I have now come around to accept Norman Cohen's approach: An unmarked >noun should be reserved for an object, e.g.: >"Target.Location.Latitude". The name of the type should be the one that >gets marked, and what better universal marker for "typeness" than >"_Type"? e.g.: > > Target : Target_Type; > Location : Location_Type; > Latitude : Latitude_Type; > Absolutely agree. After I switched from C to Ada, and could no longer use case to distinguish between instances and types, I looked at a lot of code, including Booch's original Ada components, before settling on the _type suffix, for all of the reasons Charles gave. Reading code like: The_Node.Left := Into_The_Tree.Root gave me a headache. It's hard to solve this problem in any way similar to natural language because natural languages (at least all the ones that I'm familiar with) use the same word for both a category and an instance of the category, relying on the context to disambiguate. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-09 0:00 ` Kevin Cline @ 1997-05-09 0:00 ` John G. Volan 0 siblings, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-09 0:00 UTC (permalink / raw) Kevin Cline wrote: > > "John G. Volan" <johnvolan@sprintmail.com> wrote: > > >I have now come around to accept Norman Cohen's approach: An unmarked > >noun should be reserved for an object, e.g.: > >"Target.Location.Latitude". The name of the type should be the one that > >gets marked, and what better universal marker for "typeness" than > >"_Type"? e.g.: > > > > Target : Target_Type; > > Location : Location_Type; > > Latitude : Latitude_Type; > > > > Absolutely agree. After I switched from C to Ada, and could no longer use > case to distinguish between instances and types, I looked at a lot of code, > including Booch's original Ada components, before settling on the _type > suffix, for all of the reasons Charles gave. Point of order: It wasn't Charles who said that, its was me. (It was I?) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-08 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan 1997-05-09 0:00 ` Jay Martin 1997-05-09 0:00 ` Kevin Cline @ 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` John G. Volan 2 siblings, 2 replies; 103+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-12 0:00 UTC (permalink / raw) > .... distinction between "general" > and "specific" nouns is quite ambiguous and subjective, depending on True, when you have a spectrum from general to specific, people will disagree on where the middle is. That does not invalidate the guideline. "Fido" is more specific than "Dog" which is more specific than "Quadruped". But I wouldn't accuse you of violating the guideline if you said Fido : Dog; instead of Dog : Quadruped; > context and point of view. It may take a lot of effort and hours spent > poring over Roget's Thesaurus hunting for synonyms, and then more I can not remember ever in ten years of Ada work having to spend hours poring over a thesaurus! (But congratulations for knowing the difference between "poring" and "pouring") > agonized hours deciding which synonym is more "general" .... Nor have I ever done this. See Quadruped .. Fido above > "specific". And for what? A percentage of your readers would've made > the opposite decision you made, so where does that leave readability? The fact that I would have chosen Fido : Dog; does NOT mean I would have trouble comprehending Dog : Quadruped; ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` W. Wesley Groleau (Wes) @ 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` John G. Volan 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) W. Wesley Groleau (Wes) wrote: > > > context and point of view. It may take a lot of effort and hours spent > > poring over Roget's Thesaurus hunting for synonyms, and then more > > I can not remember ever in ten years of Ada work having to spend hours > poring over a thesaurus! (But congratulations for knowing the > difference between "poring" and "pouring") > > > agonized hours deciding which synonym is more "general" .... > > Nor have I ever done this. Hyperbole! It's neat-o! Amaze your friends! :-) :-) Seriously, though: I exaggerated for rhetorical effect, my bad. Actually, I only engaged in the Thesaurus exercise _once_, while a student. Got old _really_ fast, as you can imagine. I latched onto the very first alternative to the synonym scheme that I could find (I think it was Booch's style). ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Warning: Religious naming convention discussion :-) [was: assign help!!] 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` John G. Volan @ 1997-05-12 0:00 ` John G. Volan 1 sibling, 0 replies; 103+ messages in thread From: John G. Volan @ 1997-05-12 0:00 UTC (permalink / raw) W. Wesley Groleau (Wes) wrote: > > The fact that I would have chosen > > Fido : Dog; > > does NOT mean I would have trouble comprehending > > Dog : Quadruped; These toy examples are cute, but I fail to see how they scale up to a practical scheme that works in real applications containing multiple related abstractions that must be carefully disinguished to avoid reader confusion (and sometimes author confusion). (For a very small example, see the Angle/Point/Rotation stuff I wrote in another followup to your post.) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: assign help!! 1997-05-07 0:00 ` Charles H. Sampson 1997-05-08 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan @ 1997-05-10 0:00 ` Simon Wright 1997-05-14 0:00 ` Nick Roberts 1 sibling, 1 reply; 103+ messages in thread From: Simon Wright @ 1997-05-10 0:00 UTC (permalink / raw) sampson@nosc.mil (Charles H. Sampson) writes: > This has nothing to do with the original poster's issue, but I > have to disagree with you on this naming convention. I much prefer the > one advocated by Ada Quality and Style: Type names should be general > singular nouns and object names should be specific singular nouns, ex- > cept for predicates as the names for boolean objects. (I don't just > prefer it. I had some influence on its being in AQ&S that way.) The > reason is that your program will be more readable AS AN ENGLISH SEN- > TENCE. For example > > Error_Count : Natural; > > can be read as "Error_Count is a natural number". It could even be read > as "Error_Count: Natural". Notice also, as the rationale to the naming > section of AQ&S says, it's Integer, Boolean, and Character, not Inte- > gers, Booleans, and Characters. Must say I agree with you on this one! A pity that AQ&S isn't consistent, though: see eg Message_Code_Type in 5.4.6, Element_Type in 8.3.3, and many others .. One point on derived (tagged) types; following someone else's posting on various types of Track, I find it helps to use the plural form in the package name and the undecorated singular for the type, eg package Tracks is type Track is abstract tagged private; .. package Friendly_Tracks is type Track is new Tracks.Track with private; .. package Enemy_Tracks is type Track is new Tracks.Track with private; .. Just my 2p. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: assign help!! 1997-05-10 0:00 ` assign help!! Simon Wright @ 1997-05-14 0:00 ` Nick Roberts 0 siblings, 0 replies; 103+ messages in thread From: Nick Roberts @ 1997-05-14 0:00 UTC (permalink / raw) Simon Wright <simon@pogner.demon.co.uk> wrote in article <x7vyb9n6cn1.fsf@pogner.demon.co.uk>... > One point on derived (tagged) types; following someone else's posting > on various types of Track, I find it helps to use the plural form in > the package name and the undecorated singular for the type, eg > > package Tracks is > type Track is abstract tagged private; > .. > > package Friendly_Tracks is > type Track is new Tracks.Track with private; > .. > > package Enemy_Tracks is > type Track is new Tracks.Track with private; > .. I find "ing" and "tion" handy: package Tracking is ... package Friendly_Tracking is ... package Enemy_Tracking is ... package Stacking is ... package Queuing is ... package Text_Compression is ... package Packet_Encoding is ... and so on. Nick. ^ permalink raw reply [flat|nested] 103+ messages in thread
end of thread, other threads:[~1997-05-20 0:00 UTC | newest] Thread overview: 103+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-05-05 0:00 assign help!! Ivan Gou 1997-05-06 0:00 ` Michael F Brenner 1997-05-07 0:00 ` Charles H. Sampson 1997-05-08 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan 1997-05-09 0:00 ` Jay Martin 1997-05-09 0:00 ` John G. Volan 1997-05-09 0:00 ` Jeff Carter 1997-05-09 0:00 ` John G. Volan 1997-05-10 0:00 ` Aaron Metzger 1997-05-11 0:00 ` Simon Wright 1997-05-11 0:00 ` Robert Dewar 1997-05-11 0:00 ` Robert A Duff 1997-05-12 0:00 ` Robert Dewar 1997-05-12 0:00 ` Robert A Duff 1997-05-12 0:00 ` Robert Dewar 1997-05-13 0:00 ` Robert A Duff 1997-05-13 0:00 ` Kaz Kylheku 1997-05-14 0:00 ` Robert A Duff 1997-05-14 0:00 ` Kevin Cline 1997-05-14 0:00 ` Robert Dewar 1997-05-13 0:00 ` Robert Dewar 1997-05-14 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-05-13 0:00 ` David L Brown 1997-05-13 0:00 ` W. Wesley Groleau (Wes) 1997-05-14 0:00 ` Robert Dewar 1997-05-11 0:00 ` John G. Volan 1997-05-12 0:00 ` Kaz Kylheku 1997-05-12 0:00 ` John G. Volan 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` John G. Volan 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` Robert I. Eachus 1997-05-13 0:00 ` John G. Volan 1997-05-13 0:00 ` Robert Dewar 1997-05-16 0:00 ` Robert I. Eachus 1997-05-17 0:00 ` Robert Dewar 1997-05-11 0:00 ` Kevin Cline 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` Robert Dewar 1997-05-16 0:00 ` Wayne Magor 1997-05-16 0:00 ` Robert Dewar 1997-05-18 0:00 ` Nick Roberts 1997-05-20 0:00 ` naming convention discussion Peter Hermann 1997-05-16 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] John G. Volan 1997-05-14 0:00 ` Ben Brosgol 1997-05-14 0:00 ` naming convention: trailing underscore Peter Hermann 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Michael F Brenner [not found] ` <dewar.863717431@merv> 1997-05-16 0:00 ` naming convention discussion Peter Hermann 1997-05-16 0:00 ` Robert Dewar 1997-05-20 0:00 ` Peter Hermann 1997-05-16 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Robert A Duff 1997-05-18 0:00 ` Underscores in identifiers (was: Warning: Religious naming convention discussion :-) Ben Brosgol 1997-05-17 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Arthur Schwarz 1997-05-17 0:00 ` Robert Dewar 1997-05-17 0:00 ` John G. Volan 1997-05-18 0:00 ` Andrew Dunstan 1997-05-18 0:00 ` Nick Roberts 1997-05-19 0:00 ` John G. Volan 1997-05-19 0:00 ` John G. Volan 1997-05-10 0:00 ` Kaz Kylheku 1997-05-10 0:00 ` John G. Volan 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` John G. Volan 1997-05-13 0:00 ` W. Wesley Groleau (Wes) 1997-05-13 0:00 ` John G. Volan 1997-05-14 0:00 ` Do-While Jones 1997-05-14 0:00 ` John G. Volan 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Tangent to Religious naming convention discussion W. Wesley Groleau (Wes) 1997-05-15 0:00 ` John G. Volan 1997-05-14 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Stephen Leake 1997-05-14 0:00 ` naming convention discussion Peter Hermann 1997-05-14 0:00 ` John G. Volan 1997-05-14 0:00 ` Peter Hermann 1997-05-14 0:00 ` John G. Volan 1997-05-15 0:00 ` Peter Hermann 1997-05-15 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` Warning: Religious naming convention discussion :-) [was: assign help!!] Jeff Carter 1997-05-12 0:00 ` John G. Volan 1997-05-09 0:00 ` John G. Volan 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` John G. Volan 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` John G. Volan 1997-05-11 0:00 ` Doug Smith 1997-05-12 0:00 ` Tom Moran 1997-05-16 0:00 ` Wayne Magor 1997-05-16 0:00 ` John G. Volan 1997-05-17 0:00 ` Kevin Cline 1997-05-19 0:00 ` Doug Smith 1997-05-09 0:00 ` Kevin Cline 1997-05-09 0:00 ` John G. Volan 1997-05-12 0:00 ` W. Wesley Groleau (Wes) 1997-05-12 0:00 ` John G. Volan 1997-05-12 0:00 ` John G. Volan 1997-05-10 0:00 ` assign help!! Simon Wright 1997-05-14 0:00 ` Nick Roberts
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox