Re: Naming of Tagged Types and Associated Packages

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

[I just noticed that Matthew picked up this thread again over here on
comp.lang.ada. There's a lot to comment on, so I may need more than one post.]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > Ada's mechanism is to force the identifiers to be literally different,
> > which means either adding some kind of noise word to one or the other,
> > or resorting to abbreviation for one or the other. Many react with
> > distaste to either prospect, because they recognize both as catering
> > to the programming language, and not to the problem domain concept we
> > are trying to express. (Remember, the noun phrase in question is
> > presumed to be both necessary and sufficient to express the concept.)
> > Adding noise seems less obnoxious than abbreviation. So what's the
> > least obnoxious noise you can add?
> 
> I do this sort of thing too:
> 
>    PDW : Pulse_Descriptor_Word;
> 
>    SOI : Signal_Of_Interest;

I thought one assumption in this discussion was that we were trying to find
schemes that would allow us to avoid abbreviations.  But if abbreviations
were fair game, then there would never have been an issue:

     type Color is ...

     type Car is record
       C : Color;
       ...
     end record;

     C : Car; 

     ... C.C ... -- so nice and readable! :-)

However, I think we can do a lot better than that ...

[...snip...]

> > On the other hand, let's suppose "File_Mode" is a necessary and
> > sufficient phrase to express the whole sense of the concept
> > (presumably within a use-ophilic environment).  Maybe you can get away
> > with dropping the "File_" adjective for a variable within the package,
> > but can you always do that outside the package, in all its conceivable
> > clients?  What if there's a context where you have both a "File_Mode"
> > and some other kind of mode, say an "Operational_Mode" (e.g., Real vs.
> > Simulated)?  Then it becomes important to use the complete names for
> > those concepts, including the "File_" and "Operational_" prefixes, not
> > just in their type names but also in the variable names.  If we now
> > need "File_Mode" and "Operational_Mode" as variable names, what should
> > the types have been called?
> 
> That does happen sometimes, especially subprogram parameters.  I would
> probably do something like this:
> 
>   procedure Op
>      (File  : in out File_Type;
>       FMode : in     File_Mode;
>       OMode : in     Operation_Mode);

So when push comes to shove, you advocate that we give up on English and
resort to ad-hoc abbreviations?  Why "FMode" and "OMode", particularly? 
Why not "Filmod" and "Opmod"? or "FileM" and OperatM"?  Indeed, why not
just "FM" and "OM"?

When I code, one principle I strive for is "No Synonyms":  As much as
possible, I'll try to use exactly one term to designate one concept. 
When that term is expressed in full English words (e.g., "File_Mode"),
it's not too hard to keep to a single spelling.  But once you start
abbreviating, it's too easy to proliferate a lot of alternate
abbreviations for the same thing, even in the same code module!  I've
seen it happen, and it's not pretty.

You can say it's a matter of taste, but a lot of what we've been
discussion is just taste.

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE