Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

["John G. Volan" <johnvolan@sprintmail.com>]

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? :-) ");
------------------------------------------------------------------------